Subject: [Ace] Terms to avoid

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 12 Dec 2013 19:51:26 +0100 (CET)

Could you guys do me a favor and avoid two terms in your drafts:

1) Bootstrapping

2) Trust

The term bootstrapping was created a couple of years ago as a sort of marketing term. It means "key distribution". Let us use key distribution (or key establishment) instead since we know what it means. There are a number of key distribution protocols out there and we quickly see the relationship to prior work.

The term "trust" by itself is extremely vague. So you better avoid it or be a bit more specific by saying "who trust whom to do what".

Ciao

Hannes

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 12 Dec 2013 14:59:21 -0600

Hi Hannes,

On Thu, Dec 12, 2013 at 12:51 PM, Hannes Tschofenig <
[email-masked]> wrote:

> The term bootstrapping was created a couple of years ago as a sort of
> marketing term. It means "key distribution". Let us use key distribution
> (or key establishment) instead since we know what it means. There are a
> number of key distribution protocols out there and we quickly see the
> relationship to prior work.
>
>

I have this in my draft. It is defined as
Bootstrapping is any processing required before the network can operate.

So following your suggestion, I should change it to key establishment when
the constrained node joins the network?

Regards,

Behcet

> The term "trust" by itself is extremely vague. So you better avoid it or
> be a bit more specific by saying "who trust whom to do what".
>
> Ciao
> Hannes
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>
>

---

From: "Akyol, Bora A" <[email-masked]>
Date: Thu, 12 Dec 2013 21:19:54 +0000

Hi Behcet

Is key establishment the only step required?

Usually when I use the word bootstrapping, I include all steps needed to get an operational environment. This could include key establishment, trust root provisioning (if required), discovery of network services, etc.

I do agree that we should be specific in what we mean by bootstrapping, but I do not support a regexp-replace to key establishment/distribution.

Thanks

Bora

From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 12, 2013 at 12:59 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] Terms to avoid

Hi Hannes,

On Thu, Dec 12, 2013 at 12:51 PM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Could you guys do me a favor and avoid two terms in your drafts:

1) Bootstrapping
2) Trust

So following your suggestion, I should change it to key establishment when the constrained node joins the network?

Regards,

Behcet

Ciao
Hannes

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 12 Dec 2013 23:17:29 +0100

> Could you guys do me a favor and avoid two terms in your drafts: 

I completely agree about the term “Trust”.  This is neither an objective nor a method.
When people talk about “trust” they usually either talk about the ability to authenticate something and/or an authorization relationship, but it is rarely fully fleshed out what specifically is meant.
(Some, but not all, of the uses of the term “certificate” are of the same kind.)
Device B doesn’t “trust” device A, but device A is authorized to perform certain, well-defined operations on or relevant for device B, and that authorization (as well as the origin of the operation and/or communication channels) can be authenticated in the course of performing the operation.

I don’t agree about not using bootstrapping.  Bootstrapping is not a method, it is an objective, which can be pinpointed pretty precisely in the lifecycle of a device.
More specifically, it relates to achieving the transition from a sparse or minimal, pre-operational set of authenticated authorizations to a set that can be used operationally.
(Key establishment is usually part of what needs to be done there, but the keys just serve to authenticate the authorizations, so I’m not even sure they are very important for defining bootstrapping.)

I’m sorry for this dense terminology attack, but I agree that we need to work on some of the terminology now to generate a credible charter.

Grüße, Carsten

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 12 Dec 2013 16:22:54 -0600

Hi Carsten,

Thanks for the clarification.

I completely agree with you.
I was having nightmares on how to replace bootstrapping.

Regards,

Behcet

On Thu, Dec 12, 2013 at 4:17 PM, Carsten Bormann <[email-masked]> wrote:

> When people talk about “trust” they usually either talk about the ability
> to authenticate something and/or an authorization relationship, but it is
> rarely fully fleshed out what specifically is meant.
> Device B doesn’t “trust” device A, but device A is authorized to perform
> certain, well-defined operations on or relevant for device B, and that
> authorization (as well as the origin of the operation and/or communication
> channels) can be authenticated in the course of performing the operation.
>
> I don’t agree about not using bootstrapping.  Bootstrapping is not a
> method, it is an objective, which can be pinpointed pretty precisely in the
> lifecycle of a device.
> More specifically, it relates to achieving the transition from a sparse or
> minimal, pre-operational set of authenticated authorizations to a set that
> can be used operationally.
> (Key establishment is usually part of what needs to be done there, but the
> keys just serve to authenticate the authorizations, so I’m not even sure
> they are very important for defining bootstrapping.)
>
> I’m sorry for this dense terminology attack, but I agree that we need to
> work on some of the terminology now to generate a credible charter.
>
> Grüße, Carsten
>

---

From: Likepeng <[email-masked]>
Date: Fri, 13 Dec 2013 10:15:46 +0000

>we need to work on some of the terminology now to generate a credible charter.

I checked RFC 4949 "Internet Security Glossary, Version 2", this RFC defines a lot of security related terms. We can reuse the terminologies defined in this document. 

I checked our charter, for some terms, we can find definitions, but there are no definitions for "bootstrap", "authorization information" and "access token".

For "bootstrap", the definition from OMA is: the process of provisioning the client to a state where it is able to initiate a management session to a new server.
It is quite similar to what Carsten and Behcet have described. 

For "authorization information", we can change it to the term defined in RFC 4949, maybe authorization credentials?

For "access token", there is no definition in RFC 4949, but there are definitions for "access" and "token". It should be fine to use "access token" or just "token".

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Carsten Bormann
发送时间: 2013年12月13日 6:17
收件人: Hannes Tschofenig
抄送: [email-masked]
主题: Re: [Ace] Terms to avoid

I completely agree about the term “Trust”.  This is neither an objective nor a method.
When people talk about “trust” they usually either talk about the ability to authenticate something and/or an authorization relationship, but it is rarely fully fleshed out what specifically is meant.
(Some, but not all, of the uses of the term “certificate” are of the same kind.) Device B doesn’t “trust” device A, but device A is authorized to perform certain, well-defined operations on or relevant for device B, and that authorization (as well as the origin of the operation and/or communication channels) can be authenticated in the course of performing the operation.

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 13 Dec 2013 12:32:46 +0100

> For "access token", there is no definition in RFC 4949, but there are definitions for "access" and "token". It should be fine to use "access token" or just "token".

I think the RFC4949 definition of 'token' doesn't quite match what we mean:

"   $ token
	...
       2. (I) /access control/ An object that is used to control access
       and is passed between cooperating entities in a protocol that
       synchronizes use of a shared resource. Usually, the entity that
       currently holds the token has exclusive access to the resource.
       (See: capability token.)
"

The way draft-selander (and draft-gerdes if I'm not mistaken) defines 
the use of tokens, they don't give _exclusive_ access.

Also if you look at 'capability token':

"	... Possession of the token is accepted by a system as proof
	that the holder has been authorized to access the resource
	 indicated by the token.
"

That also isn't quite in line with draft-selander and draft-gerdes, 
since both define some subject-binding in the token.

I'd prefer to use "authorization credential" instead of "authorization 
token".

"Authorization information" is a really vague term, but the analogue 
"authentication information" is used several times in RFC4949 without 
being defined, so perhaps we can get away with using it anyway.

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Dec 2013 12:54:51 +0100

On Dec 13 2013, at 11:15, Likepeng wrote:

> RFC 4949

I agree that we should use 4949 for everything that's in there.

But we are trying to do new things.
So it is not too surprising that there are gaps.

We shouldn't try to use 4949 terms that don't quite fit what we are  
doing; here we should be bold enough to make our own terms.

Grüße, Carsten

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 13 Dec 2013 13:14:43 +0100 (CET)

The response I get from both of you shows me already that there is a problem.

Behcet responded that it is "Bootstrapping is any processing required before the network can operate."

This is obviously incredibly broad although his draft only says that we should leverage the AAA architecture (which is a perfectly fine thing to say as a solution). The AAA framework does not speak about bootstrapping and so one might one why it was possible to get away without that term back on those days.

Carsten says: "Bootstrapping is not a method, it is an objective, which can be pinpointed pretty precisely in the lifecycle of a device.

More specifically, it relates to achieving the transition from a sparse or minimal, pre-operational set of authenticated authorizations to a set that can be used operationally."

Carsten, you are pointing to a lifecycle that seems to be universally agreed. Where is that lifecycle? The definition you offer is also vague and IMHO does not help to guide the work in the group.

Let me try a different approach. There are two basic approaches that I have seen so far in context of security relevant to this debate:

1) You already have a secret pre-provisioned on the device. You want to leverage that existing secret to access new services. This is what this key distribution / key establishment stuff is all about. This is the typical three party protocol (that some of the referenced documents use). Examples I have seen are Behcet's AAA proposal, or the OAuth flavor of draft-selander-core-access-control. Kerberos belongs to that category as well and so would models with certificates (where the trusted third party is the CA that issues the certificates).

2) You have no secret pre-provisioned. The approaches here are sometimes referred as imprinting or pairing.  The solutions often make use promitity techniques that require user involvement and their approach varies hugely depending on the hardware capability of the device. You can find a short summary at the smart object security workshop (see http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop-02#section-3.4) and obviously a lot of literature on that subject.

It seems that the charter focuses on (1). If that's the case you should say that.

Assuming the group wants to go for #1 then the aim of the group is to look at existing key distribution protocols and see which one fits best to the IoT environment. Maybe there are some additional requirements that require extensions (or even a completely new protocol?!?).

One important implication of going for (1) is that there is obviously this key distribution center (KDC)/AAA server/CA/authorization server that needs to be somewhere (although it does not need to be in the local network). I was wonder whether folks have become aware of that since it may feel a bit foreign in some of the scenarios (just think about having a KDC or a AAA server in your home, for example).

Ciao

Hannes

Gesendet: Donnerstag, 12. Dezember 2013 um 22:22 Uhr

Von: "Behcet Sarikaya" <[email-masked]>

An: "Carsten Bormann" <[email-masked]>

Cc: "Hannes Tschofenig" <[email-masked]>, [email-masked]

Betreff: Re: [Ace] Terms to avoid

Hi Carsten,

Regards,

Behcet

Grüße, Carsten

Ace mailing list

[email-masked]

_______________________________________________ Ace mailing list [email-masked] https://www.ietf.org/mailman/listinfo/ace

---

From: Stefanie Gerdes <[email-masked]>
Date: Fri, 13 Dec 2013 13:57:08 +0100

Hi everybody,

> For "authorization information", we can change it to the term defined in RFC 4949, maybe authorization credentials?

I assume you refer to this definition of credentials: "A data object
that is a portable representation of the association between an
identifier and one or more access authorizations, and that can be
presented for use in verifying those authorizations for an entity that
attempts such access."

I don't really like the term "credentials" for authorization because  in
my opinion it is too closely connected to authentication. I really want
to avoid getting authentication and authorization even more mixed up
than they are already.

Authorization information is the information that provides the resource
server with the means to know which resources a client might access and
how. Yes, this is a bit vague, but we are not sure at this point what
this information should look like. This is the point of the task "Define
an access token and authorization information format suitable for
constrained devices".

> For "access token", there is no definition in RFC 4949, but there are definitions for "access" and "token". It should be fine to use "access token" or just "token".

I am still in favour of using the term "access ticket". It is intuitive
because a ticket is something you show to someone to get access, even in
the real world. Note that Kerberos didn't invent the term but used it
because it is fitting.

Best regards,
Steffi

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Dec 2013 14:07:08 +0100

On Dec 13 2013, at 13:14, Hannes Tschofenig wrote:

> Carsten says: "Bootstrapping is not a method, it is an objective,  
> which can be pinpointed pretty precisely in the lifecycle of a device.
> More specifically, it relates to achieving the transition from a  
> sparse or minimal, pre-operational set of authenticated  
> authorizations to a set that can be used operationally."
>
> Carsten, you are pointing to a lifecycle that seems to be  
> universally agreed. Where is that lifecycle?

draft-garcia

> The definition you offer is also vague and IMHO does not help to  
> guide the work in the group.

It is pretty much as un-vague as it can be.

If that makes you uncomfortable because it doesn't immediately lead to  
a separable "bootstrap protocol", I'm with you.
I would be very unhappy if we needed a separate piece of technology  
for bootstrapping.
Bootstrapping is just one area among the set of requirements this work  
needs to meet.
If several good ways to do bootstrapping don't fall naturally out of  
the ACE work, we have failed.

Re 1 and 2: both, of course.

Maybe it's best to stop thinking about these keys for a moment.
Keys are a means to an end.
What is the end?
Thinking about this might help prevent us from getting another key  
establishment protocol that only addresses a bizarre subset of the  
problem.

This is all about authorization.
(Authenticated authorization, specifically.
Not Authentication and authorization as if those were separable.)

Grüße, Carsten

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 13 Dec 2013 17:41:31 +0100 (CET)

Carsten,

I always get worried when new terminology is introduced because it somehow prevents people to see the connection to earlier work anymore. I am not saying that without some experience. I have seen EU funded projects (with good people) working in different working groups (who use different terminology) to find out after two years that they have been actually working on the same problem and came up with the same solution (but just called it differently).

Just to give you an example in this conversation about terminology for access token. Where does that term come from? Hmmm. It comes from OAuth since the write-up offered in draft-selander-core-access-control-01.txt is essentially OAuth. (Of course, one has to say that the OAuth group also "re-invented" Kerberos to a large extend.) The terminology defined in the base OAuth 2.0 spec is "access token -- a string denoting a specific scope, lifetime, and other access attributes". Access token was OAuth specific and one could as well look at the Kerberos terminology for a very similar concept (the ticket) --   Ticket: A record that helps a client authenticate itself to a server; it contains the client's identity, a session key, a timestamp, and other formation, all sealed using the server's secret key.  It only serves to authenticate a client when presented along with a fresh Authenticator."

If you acknowledge that it has something to do with OAuth one can start differently, namely by saying the following: "Here is OAuth and it has the features we like in the IoT context. There are a few things we do not like (and we profile them away) and here are some additional features we need, which are X, Y, and Z." That would save us a lot of time.

Regarding your reference to the lifecycle in http://tools.ietf.org/html/draft-garcia-core-security-01 concerning bootstrapping. It shows that bootstrapping consists of the phases "installed" and "commissioned" but unfortunately it does not define them in detail. I would much more comfortable if the authors had explained it, which I raised in my review http://www.ietf.org/mail-archive/web/ace/current/msg00027.html.

Regarding your remark about not looking at the keys. Of course, key establishment protocols are not only about keys. There is more to them and authorization is part of the story. It turns out that you cannot separate all these different phases into distinct pieces. As an example, I can point to a good description about the AAA framework: http://tools.ietf.org/search/rfc5247 (Of course it has the AAA alike communication framework underneath, which you may or may not like.)

I think I am really not asking for too much here, I believe. All I am looking for is for the group to take existing IETF work (terminology, and concepts) into account and if it cannot be used then to describe it clearly what the new things does. Am I asking for too much?

Ciao

Hannes

Gesendet: Freitag, 13. Dezember 2013 um 13:07 Uhr

Von: "Carsten Bormann" <[email-masked]>

An: "Hannes Tschofenig" <[email-masked]>

Cc: "Carsten Bormann" <[email-masked]>, [email-masked], [email-masked]

draft-garcia

for bootstrapping.

needs to meet.

What is the end?

problem.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 14 Dec 2013 19:37:14 -0500

> 1) You already have a secret pre-provisioned on the device. You want to
> leverage that existing secret to access new services. This is what this key
> distribution / key establishment stuff is all about. This is the typical
> three party protocol (that some of the referenced documents use). Examples
> I have seen are Behcet's AAA proposal, or the OAuth flavor of
> draft-selander-core-access-control. Kerberos belongs to that category as
> well and so would models with certificates (where the trusted third party
> is the CA that issues the certificates).

Would you include situations where the "secret" is imprinted upon a bar/QR
code on the packaging under (1)?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Likepeng <[email-masked]>
Date: Mon, 16 Dec 2013 03:28:37 +0000

From Ludwig: 
>I'd prefer to use "authorization credential" instead of "authorization token".

From Stefanie:
>I am still in favor of using the term "access ticket". It is intuitive because a ticket is something you show to someone to get access, even in the real world. Note that Kerberos didn't invent the term but used it because it is fitting.
>I don't really like the term "credentials" for authorization because in my opinion it is too closely connected to authentication. I really want to avoid getting authentication and authorization even more mixed up than they are already.

From RFC 4949:

   $ ticket
      (I) Synonym for "capability token".

      Tutorial: A ticket is usually granted by a centralized access
      control server (ticket-granting agent) to authorize access to a
      system resource for a limited time. Tickets can be implemented
      with either symmetric cryptography (see: Kerberos) or asymmetric
      cryptography (see: attribute certificate).

   $ credential
2. (I) /access control/ "authorization credential": A data object
      that is a portable representation of the association between an
      identifier and one or more access authorizations, and that can be
      presented for use in verifying those authorizations for an entity
      that attempts such access. Example: X.509 attribute certificate.
      (See: capability token, ticket.)

From the explanations above, "ticket" and "credential" are quite similar in terms of authorization. But credential has more usages, for example, authentication.

If we want to avoid confusion, "ticket" is better than "credential" in our context.

Kind Regards
Kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Ludwig Seitz
发送时间: 2013年12月13日 19:33
收件人: [email-masked]
主题: Re: [Ace] Terms to avoid

"   $ token
	...

The way draft-selander (and draft-gerdes if I'm not mistaken) defines the use of tokens, they don't give _exclusive_ access.

That also isn't quite in line with draft-selander and draft-gerdes, since both define some subject-binding in the token.

I'd prefer to use "authorization credential" instead of "authorization token".

"Authorization information" is a really vague term, but the analogue "authentication information" is used several times in RFC4949 without being defined, so perhaps we can get away with using it anyway.

/Ludwig

--
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 16 Dec 2013 10:05:27 +0100

On 12/16/2013 04:28 AM, Likepeng wrote:
>> I am still in favor of using the term "access ticket".
[...]

> If we want to avoid confusion, "ticket" is better than "credential" in our context.

Why not just have a poll? I don't want to drag this discussion on more 
than necessary and I'm willing to accept a majority consensus (as long 
as the majority is more than 3 people).

Would this format be acceptable?
========================================================================

Question: Which is the best (as in "creating the least confusion") term 
for a data object carrying authorization information (See RFC4949 for 
definitions of the suggested terms):

[ ] access ticket, short: ticket
[ ] authorization credential, short: credential
[ ] authorization token, short: token
[ ] other (please state why):

/Ludwig
========================================================================

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 16 Dec 2013 10:18:00 +0100

On 16 Dec 2013, at 10:05, Ludwig Seitz <[email-masked]> wrote:

> Why not just have a poll? 

Do we know what it is the name of which we are deciding?
I haven’t seen a discussion of a definition.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Dec 2013 21:17:37 +0000

Hi Michael,

> code on the packaging under (1)?

Good question as well. 

The issue is that you can actually mix the different models together in
a single deployment because there is more than one credential.

For example, think about your WLAN access point (which most likely has
the secret printed on the bottom of the box). There you will most likely
use the secret for actually configuring the device. Instead of sending
you a letter with the password the manufacturer decided to print the
secret directly onto the box (which makes a lot of sense since you are
less likely to find they key later.

So, in that case this is just a regular out-of-band key provisioning
between two parties. The difference to the imprinting case is (if I
understood the terminology correctly) that the two devices do not have
anything provisioned prior to the exchange.

That's my understanding.

Ciao
Hannes

---

From: Likepeng <[email-masked]>
Date: Tue, 17 Dec 2013 01:03:00 +0000

>Do we know what it is the name of which we are deciding?

It is about the "access token" in the charter.
- Define an access token and authorization information format suitable for constrained devices.

Two proposals so far: 
[1] access ticket, short: ticket
[2] authorization credential, short: credential [ ] authorization token, short: token [ ] other

>I haven’t seen a discussion of a definition.

Definitions from RFC4949:

   $ ticket: A ticket is usually granted by a centralized access
      control server (ticket-granting agent) to authorize access to a
      system resource for a limited time. 

   $ credential

Kind Regards
kepeng

-----邮件原件-----
发件人: Ace [mailto:[email-masked]] 代表 Carsten Bormann
发送时间: 2013年12月16日 17:18
收件人: Ludwig Seitz
抄送: [email-masked]
主题: Re: [Ace] Terms to avoid

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 17 Dec 2013 11:10:22 +0100

> - Define an access token and authorization information format suitable for constrained devices.

Yes.  What I was (tersely) trying to say was that we should define what that is before we decide on a name for it.
For that discussion, both “token” and “ticket” are fine.
(I’m not a big fan of “credential”, but that is because I have a mental image of what that thing should be.)

Grüße, Carsten

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 17 Dec 2013 11:21:52 +0100

> (I’m not a big fan of “credential”, but that is because I have a mental image of what that thing should be.)

Perhaps my attempt to define it was too unspecific:

  "a data object carrying authorization information"

But if I may expand on this and suggest the following:

"a data object carrying information about an authorization decision"

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Likepeng <[email-masked]>
Date: Wed, 18 Dec 2013 00:59:16 +0000

From Ludwig:
>Steffanie Gerdes, Olaf Bergmann, Göran Selander and I had agreed to call those things 'tokens' or 'authorization tokens'. Would that be "consensusable"?

To make a summary of the discussion, let's keep "token" for now in the charter. 

We can change later if we have better proposals.

Thanks,

Kind Regards
Kepeng

-----邮件原件-----
发件人: Carsten Bormann [mailto:[email-masked]] 
发送时间: 2013年12月17日 18:10
收件人: Likepeng
抄送: Ludwig Seitz; [email-masked]
主题: Re: [Ace] Terms to avoid

Grüße, Carsten