Subject: A personal take on WG's priorities..

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Nov 2004 08:40:59 +0200 (EET)

Hi,

Based on the discussion on what the WG should be doing, I cooked up my 
**personal** list of what I consider to be priorities, in some rough 
categories.  As you see, there's a *LOT* that falls under the WG 
charter, and there is no way we could work on even 1/3 or 1/4 of these 
at the same time.  So, there must be some priorization.

I welcome comments especially if you think I've badly misprioritized 
document/work that relates to the v6ops charter.

======

The most important work
  - finish enterprise analysis
  - finish requirement(s) for tunneling
     * to be able to decide whether existing solution(s) are sufficient
       and if not, get started on specifying new ones
  - get started on mechanisms (somewhere else?) if needed/necessary

Pretty darn important work
  - the last spin at 3GPP analysis doc, updated IMS scenario
  - better document the ISP's broadband transition scenarios
     * draft-asadullah-v6ops-bb-deployment-scenarios-01
  - finish draft-ietf-v6ops-mech-v2
     * waiting for feedback from the IESG telechat..
  - adopt and finish draft-tschofenig-v6ops-secure-tunnels-02.txt
     * IESG requirement for draft-ietf-v6ops-mech-v2
  - figure what to do about the NAT-PT deprecation/analysis
    *  draft-aoun-v6ops-natpt-deprecate
  - (techno-political) document for v4 NAT users
    * draft-vandevelde-v6ops-nap
  - IPv6-on-by-default work, fixes need to be integrated in the IETF work
    * draft-ietf-v6ops-onlinkassumption
    * draft-ietf-v6ops-v6onbydefault
    * etc.

Important work
  - draft-ietf-v6ops-renumbering-procedure
    * needs revision to address IESG comments
  - draft-palet-v6ops-tun-auto-disc
  - draft-chown-v6ops-vlan-usage
  - figuring out how to deal with Mobile IP transition issues
  - security overview of IPv6
     * draft-savola-v6ops-security-overview

Useful work
  - revising 6to4 spec to be clearer, etc.
  - draft-palet-v6ops-solution-tun-auto-disc
  - draft-chown-v6ops-renumber-thinkabout-00
  - draft-chown-v6ops-port-scanning-implications

Difficult to say whether it has gained sufficient momentum, and/or
  whether this is the right place to do this
  - draft-palet-v6ops-auto-trans
  - draft-palet-v6ops-ipv6security
  - draft-vives-v6ops-ipv6-security-ps
  - draft-kondo-quarantine-overview-01.txt

Not sure whether it should be published as RFC, or is sufficiently relevant
  - draft-chown-v6ops-campus-transition
  - draft-morelli-v6ops-ipv6-ix

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Nov 2004 09:09:44 +0100

Pekka,

Loosely speaking, this list seems OK to me personally.

Quite obviously, it would be outrageous to attempt all this
in one WG. IMHO, we need to either out-source work to other
WGs or create several new WGs with focussed charters.
Especially, we need to separate "getting known stuff
fully operational" from "doing new stuff."

    Brian

---

From: "EricLKlein" <[email-masked]>
Date: Thu, 4 Nov 2004 10:30:27 +0200

From: "Brian
> fully operational" from "doing new stuff."

Is it possible to try to set up "sub-WG" areas and recruit more specialized
people into these areas?

I am thinking (of the top of my head) of three subgroups:
- Enterprise - would include migration issues, etc.
- ISPs - would handle tunnels, interconnections, etc
- IPv6 Security - would handle NAT-PT, depreciating NAT in IPv6, etc.

Just a thought.
Eric

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 04 Nov 2004 10:55:21 +0100

Hi Brian,

May be I'm wrong, but if the objective to outsource some of the work is to
"evacuate" it faster, I think is not the right way.

I mean, if they are within the charter, they are operational issues, pushing
it outside, will mean some of the people that is doing effort here, will
divide his time following up to WGs (at least), attending 2 meetings, etc.
At the end, some times this can be rather more time consuming that
proceeding here. I've this experience in projects, when you divide the work
in several WGs and then becomes fragmented, and the people, who is limited
in number and resources, availability, etc., tend to keep only with part of
the work, very concentrated and missing the overall picture.

Consequently, I will agree with this only in case we have extra effort,
which is not the case, but in general in IETF on the contrary. Less people
less effort with the time ..., unfortunately.

I will agree that if we have something that is clearly specific to an
existing WG, then it should be forwarded there. Similarly, if there is some
work that requires a very focused effort, then we should try to create a new
WG, probably.

Regards,
Jordi

> De: Brian E Carpenter <[email-masked]>
> Organización: IBM
> Responder a: [email-masked]
> Fecha: Thu, 04 Nov 2004 09:09:44 +0100
> Para: Pekka Savola <[email-masked]>
> CC: [email-masked]
> Asunto: Re: A personal take on WG's priorities..
> 
> Pekka,
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 04 Nov 2004 11:22:01 +0100

Hi Pekka,

In general good proposal. I will like to suggest some changes, see below,
already prioritized following the criteria that I think is required, and
simplified a little bit.

Regards,
Jordi

Group 1
> - get started on mechanisms (somewhere else?) if needed/necessary

I will say that is not good that a new WG should take care of new mechanisms
(if they are required). This will slow down the process too much (minimum 6
months), and it not clear that we can't do that with the current charter, or
even a small modification of it.

Also, I think this
> - draft-palet-v6ops-tun-auto-disc
belongs to what I called Group 1, and is ready to be closed. Otherwise will
be good the received inputs, objections or whatever !

Group 2
>   * draft-ietf-v6ops-v6onbydefault
I think
> - draft-palet-v6ops-solution-tun-auto-disc
belongs to this group, and is 80% ready. Is very useful for the zeroconfig,
assisted tunneling, etc.

Group 3
>    * draft-savola-v6ops-security-overview

Group 4
> - draft-chown-v6ops-port-scanning-implications

Group 5
> - draft-kondo-quarantine-overview-01.txt

I'm tempted to move all this to the Group 2 or 3, together with the
security-overview. If this work needs to specify new protocols, then I might
consider another WG (existing probably, not necessarily a new one), but I
believe it can be approached with existing protocols within IETF.
I consider security an extremely important issue for the deployment of IPv6,
as an operational issue that falls clearly in the scope of our charter.

By the way, I don't think is a question of momentum, is a question of people
reviewing, and we all know that the problem is the same with other very
important documents, which at the end pass by "no objection" despite Jim
observations ! Let's be honest with ourselves, please ! I think is very
stupid to try to convince ourselves about what is so evident. And yes is my
own fault also, I will like to do more work review more documents, but
specially the last 3-4 months has been almost impossible. Now I've plenty of
time during Xmas and will do much more.

Group 6
> - draft-morelli-v6ops-ipv6-ix

Not sure either, but I will say is part of the scenarios documents.

My conclusion is that we will have probably only 3 groups instead of 6,
which can proceed almost in parallel, even if takes a few extra months
(3-6), because that will be the same delay it will take creating a new WG,
or even outsourcing to existing ones.

Missing items, other future candidate work which fall in the actual charter
? Work that is very close related and requires a charter modification to be
approached here, if its the best place to be done ?

Views from the rest of the WG, please ?

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Fecha: Thu, 4 Nov 2004 08:40:59 +0200 (EET)
> Para: [email-masked]
> Asunto: A personal take on WG's priorities..
> 
> Hi,
>

---

From: "Sham Chakravorty" <[email-masked]>
Date: Thu, 4 Nov 2004 08:24:29 -0500

In this regard, would it make sense to add IPv6 Flow Label usage in a
"sub-WG" area such as Enterprise or IPv6 Traffic Modeling?  One would think
this is one of the  key IPv6 operations areas.  It seems to me we are
focused only in a few, narrowly focused areas of IPv6 operations (as
reflected in the charter).

Sham Chakravorty

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of EricLKlein
Sent: Thursday, November 04, 2004 3:30 AM
To: [email-masked]
Subject: Re: A personal take on WG's priorities..

From: "Brian

Just a thought.
Eric

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 4 Nov 2004 07:39:59 -0600

FWIW, the SIP community has been reasonably effective in "dividing and 
conquoring" with at least SIP, SIPPING ("the kidney of the SIP 
community", to quote Dean Willis, and I don't know who said it first), 
XCON, SIMPLE, plus a few million ad hoc discussions.

My impression from the outside is that Jordi correctly points out the 
challenges:

- SIP and SIPPING share two out of three WG chairs, so coordination is 
tighter but the load on the chairs is heavier,

- Core specifications may be WGLCed in multiple WGs (SIP and SIPPING, 
for example), to make sure everyone is in the loop,

- Ideas that span WGs may bounce around a bit (conferencing framework, 
for example).

- if you can't spend the entire IETF in SIPpish meetings, you're just 
not trying.

I also note that at least some communities in the IETF can either work 
effectively on specifications or on a charter, but not both at once. 
Is v6ops one of these communities? If so, a charter tsunami would slow 
our work down before we accelerate.

Spencer, who is trying to find a nice way to ask David, "would you 
prefer to see multiple WGs, or multiple 'sub-WGs' within v6ops?"

From: "JORDI PALET MARTINEZ" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 04, 2004 3:55 AM
Subject: Re: A personal take on WG's priorities..

Hi Brian,

May be I'm wrong, but if the objective to outsource some of the work 
is to
"evacuate" it faster, I think is not the right way.

I mean, if they are within the charter, they are operational issues, 
pushing
it outside, will mean some of the people that is doing effort here, 
will
divide his time following up to WGs (at least), attending 2 meetings, 
etc.
At the end, some times this can be rather more time consuming that
proceeding here. I've this experience in projects, when you divide the 
work
in several WGs and then becomes fragmented, and the people, who is 
limited
in number and resources, availability, etc., tend to keep only with 
part of
the work, very concentrated and missing the overall picture.

Consequently, I will agree with this only in case we have extra 
effort,
which is not the case, but in general in IETF on the contrary. Less 
people
less effort with the time ..., unfortunately.

I will agree that if we have something that is clearly specific to an
existing WG, then it should be forwarded there. Similarly, if there is 
some
work that requires a very focused effort, then we should try to create 
a new
WG, probably.

Regards,
Jordi

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Nov 2004 17:19:24 +0100

Sham, the flow label is low on my personal priority list.
The reason I was eager to get RFC 3697 done is to set boundary
conditions on its use, but developing the actual use cases
seems to me to be off the critical path for the IETF.

Looking at your email address, I can see why you might give it
higher priority - but do you need the IETF for that right now,
as long as you obey RFC 3697?

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Nov 2004 17:20:41 +0100

Jordi,

It's Management 101. I don't think any WG with so many diverse
topics has a chance of making good progress. We need to divide
and conquer, IMHO.

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Nov 2004 19:48:52 +0200 (EET)

> as long as you obey RFC 3697?

FWIW, my personal take --

It might possibly make sense to set up a mailing list on IPv6 flow 
label usage, try to solicit people to join it, propose and discuss 
various proposals... and depending on how it goes, try to run a BOF at 
the next meeting to gauge the real interest.

Even if there is not sufficient interest, I believe it's vital to 
success to get those people interested of the flow label together.

At the first stage, the product might not be an IETF standards track 
document, or even an IETF document -- e.g., an experimental RFC 
through RFC-editor developed based on the mailing list discussion, but 
that would be at least a basis for further work w/ flow label.

In other words, it's important to get those diffserv/qos geeks in the 
same list/room with IPv6 specialists and those who'd like to use flow 
label in new, innovative ways .. and see what happens.

IMHO, in any case, v6ops-like generic WGs are probably not a good 
place to get sufficient amount of interest & expertise together.

---

From: "Sham Chakravorty" <[email-masked]>
Date: Thu, 4 Nov 2004 13:45:54 -0500

Pekka, 

We have plans similar to what you suggest.  But I sincerely believe that
your WG is the place for Flow Label discussion.  If resources don't allow
such added work, then that's something that needs to be pursued.

Sham

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pekka Savola
Sent: Thursday, November 04, 2004 12:49 PM
To: Brian E Carpenter
Cc: Sham Chakravorty; [email-masked]
Subject: Re: Flow Label [Re: A personal take on WG's priorities..]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Nov 2004 21:07:33 +0200 (EET)

> even a small modification of it.

Yes, there are challenges with spinning up a new WG, but it does not 
necessarily need to take that long, and the work doesn't have to be 
stalled during the time it takes to officially kick-start a WG.

Putting all the work relating to protocols certainly seems to be a 
relatively easily separable piece of the current charter.

Now, if we take those items from the list which might be 
protocol-related, we have:

That seems a close-to-manageable list, keeping in mind that mech-v2 is 
pretty much complete in any case.  That would allow v6ops WG to better 
focus on non-protocol work items, also those you wanted to be 
addressing.

For the rest of the items, see a possible division at the end..

> be good the received inputs, objections or whatever !

I don't disagree that this is rather close to being closed, but the 
question is of its urgency -- I think it'll be needed only when we 
start figuring out which kind of protocols we specify, or how we 
modify them.  (Granted, it would be useful if there was already 
consensus on that then.)

> belongs to this group, and is 80% ready. Is very useful for the zeroconfig,

As for draft-palet-v6ops-tun-auto-disc, this seems to be needed only 
after a little bit, certainly not before the requirements document is 
moving forward.

Personally, I think this is very far from done.  I think the approach 
has serious issues relating to the need to implement a lot of 
different functions.  Of course, these could be worked out as a WG 
item as well, but being technically sound gives more weight in the 
decision for WG adoption.

> time during Xmas and will do much more.

Let me explain why I raised the need for 'momentum'.  The IETF should 
not (IMHO) work at protocols or approaches if there isn't sufficient 
'buy-in' from the associated parties (e.g., the most important vendors 
which are required to make it successful, operators willing to deploy 
the stuff, enough people interested in the specification and reviewing 
etc.).

We (IMHO) should not move forward and put out RFCs on something, even 
if some deem that important, unless there is sufficient interest in 
the work so that the work would actually be used.  The result would 
probably be 1) irrelevant work that no-one will use, and/or 2) badly 
reviewed, technically unsound work, because there was not sufficient 
attention to the work.

I think the work on distributed security is one example of this.  The 
work needs to get attention from the different players in the field, 
most importantly the security folks (who were involved in defcon), 
some vendors (like Microsoft and Cisco, who have been working on a 
proprietary solution AFAIR), etc.  -- this work seems best suited to a 
separate mailing-list, with a BOF process, etc.  A separate mailing 
list seems like the only way to get focused attention on the work: 
security etc. folks would find the v6ops list too noisy.

> Not sure either, but I will say is part of the scenarios documents.

Campus transition, yes -- if Tim and others think it's worth 
publishing.

IPv6-IX, not really, as that isn't the real operational model how 
(IPv6) exchanges are run.

> or even outsourcing to existing ones.

But these categories total like 25 documents!

As Brian said, there's no chance to work on those in parallel.  There 
_must_ be some serialization, or forking off to separate efforts. 
For example, 4-7 work items at the same time _might_ be doable, but 
some would say that even that much is a lot.

....

At the start I described some potential items for "v6mechs" WG.  Let's 
look a bit at a possible division of the rest:

Might be doable under v6ops (the middle category docs are almost done 
already, so there's only little work)
  - finish enterprise analysis
  - better document the ISP's broadband transition scenarios

  - the last spin at 3GPP analysis doc, updated IMS scenario
  - IPv6-on-by-default work, fixes need to be integrated in the IETF
  - draft-ietf-v6ops-renumbering-procedure
  - draft-chown-v6ops-vlan-usage

Might be best to run through a separate mailing lists/BOFs process, 
(possibly fold back the results to v6ops when done there):

  - figuring out how to deal with Mobile IP transition issues
  - distributed security stuff
  - draft-chown-v6ops-renumber-thinkabout-00 (maybe)
  - maybe the ipv6 flow label applicability stuff

So, provided that some work that touches multiple areas, or areas of 
expertise could be run through a separate process, the load on v6ops 
might become manageable, and it would be more realistic to think about 
taking new _operational_ work items as well.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Nov 2004 20:27:06 +0100

I like Pekka's idea to aim at a BOF at the following
IETF. But I really think this should be handled quite separately
from v6ops. It's a WG on its own.

   Brian

---

From: Tim Chown <[email-masked]>
Date: Thu, 4 Nov 2004 19:40:47 +0000

> relatively easily separable piece of the current charter.

Stepping up a mile or two, there is some appeal to having two WG threads,
be it one WG or two WGs:

WG1: "Operational issues with IPv6" that 
  a) analyses scenarios and identifies issues, documents requirements 
     from the issues
  b) produces informational documents on bcp in deployment
 
WG2: "IPv6 transition mechanisms" (ironically back to ngtrans :) that:
  a) takes requirements from WG1 and breaks out specific protocol proposals
  b) defines the protocols, may be more than one protocol per problem space,
     though ideally there is just one

> Campus transition, yes -- if Tim and others think it's worth 

For me, that I-D is a) a validator for testing ent-scenrios usefulness (which
I think it passed) and b) a place to document the transition tools we're
using on site, plus some random other issues that probably are best left
outside such an I-D :)   Some people seemed to like it though.
 
>  - finish enterprise analysis

So now we know why you and Jonne are the chairs :)

>  - draft-chown-v6ops-vlan-usage

This is kind of ready, but can wait for ent-analysis.  It's easy to point
people at a draft if they ask about it.   Most people are just doing it.
 
>  - security overview of IPv6

This is a biggie lurking low down on your list.

>  - draft-chown-v6ops-port-scanning-implications

I thought this would be part of "security overview of IPv6" but really it's
actually part of "BCP on enterprise IPv6 address planning".  After the
IETF there's a small (6NET) group working on an I-D in that area from
exerience gained to date.
 
>  - draft-chown-v6ops-renumber-thinkabout-00 (maybe)

That one is a scoping document for some 6NET-related work, also with Cisco,
and is helping us to define experiments to run to evaluate support for
renumbering in IPv6 networks.   It complements Fred's draft (RFC to be).
The audience of it is broad, not just an admin about to do a renumbering.

Tim

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 05 Nov 2004 00:40:08 +0100

Pekka,

Reply to only a minor part of your message.

This sound really weird. If you believe this is done, or almost, it make
sense to get this as WG item and make sure that the WG take a look (last
call process that we used to push the WG attention with other documents) ?

What is not sensible to me is to say, "will be needed, is almost done, but
...". I don't understand the but ! Is ridiculous to have a work done waiting
for ... may be another WG ? This will take then more time from the WG and
the IETF in general that closing it now !

Can we heard the rest of the WG opinion on this ?

Regards,
Jordi

---

From: "Liu Min" <[email-masked]>
Date: Fri, 5 Nov 2004 11:20:06 +0800

I also want to know if we want to make some suggestion or present some
proposal for IPv6 Flow Label, where should we do it. When we introduce IPv6,
the Flow Label and Traffic Class, and its support for QoS are always one
topic. However, you can not present a QoS mechanism or a network measurement
tool using Flow Label and Traffic Class, because they are still experimental
and subject to change. 

Best Wishes,

Liu Min
 
Institute of Computing Technology
Chinese Academy of Sciences
Tel: (86-10) 6256 5533-9240 
E-mail: [email-masked]

> Of Sham Chakravorty
> Sent: Thursday, November 04, 2004 9:24 PM
> To: [email-masked]
> Subject: RE: A personal take on WG's priorities..
>

---

From: Alain Durand <[email-masked]>
Date: Thu, 04 Nov 2004 23:13:54 -0800

As you ask, here is my take on all this.

Essentially, there is work needed in 4 areas:

1. Tunneling
- finish the work on assisted tunneling, zeroconf tunneling, 3GPP 
tunneling requirements
- finish the analysis of existing protocol candidates
- design new one(s) if needed
- finish the work on tunnel end-point discovery

2. Protocol maintenance
- deprecate useless mechanism
- clarify/refine some mechanism (e.g. 6to4)
- move some mechanisms along standard track

3. Operational issues
- renumbering doc
- IPv6 on by default
- operational security docs
- result from operational experience

4.  Finish the work on scenario.

A natural evolution of NGtrans/v6ops would be to shut down v6Ops
by declaring victory on (4), and create two new working group,
a short to medium term one, focusing on (1) & (2), and a long  term one 
focusing on 3.

	- Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Nov 2004 11:23:59 +0100

> tool using Flow Label and Traffic Class, because they are still experimental

This last sentence is not correct. The Traffic Class is Proposed Standard
(RFC 2474, RFC 2597, RFC 3246, RFC 3289 and others). It is operational in
IPv4, and will operate identically in IPv6.

The Flow Label general rules are Proposed Standard (RFC 3697; also see
RFC 3595). However, we still need to describe specific use cases for the
Flow Label. That is the work that needs to be done, and anyone can
publish an I-D describing a use case, and ask for a BOF.

    Brian

>>"sub-WG" area such as Enterprise or IPv6 Traffic Modeling?  One would
> 
> think
> 
>>Is it possible to try to set up "sub-WG" areas and recruit more
> 
> specialized
> 
>>people into these areas?
>>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 5 Nov 2004 12:40:27 +0200 (EET)

On Thu, 4 Nov 2004, Alain Durand wrote:
> - finish the work on assisted tunneling, zeroconf tunneling, 3GPP tunneling 
> requirements

1 and 2 are certainly separable pieces of this puzzle.  However, it is 
important to put in place good policies on which kind of new tunneling 
work would be accepted (would it e.g., require a rechartering) so that 
the "v6mechs" WG would not become a "swamp".

3 and 4 are something that could be doable by "trimmed-down" v6ops; 
I'd see no particular use in shutting down a WG and springing up a new 
one in its place.  (4) needs to be finished, and there might be useful 
work coming down at that pipe down the road (like the BB ISP 
document).  I don't think the WG would need to initiate actively new 
work on 4, but if there were solid proposals on better documentation 
of existing scenarios, I don't see why that could not be documented.

---

From: "EricLKlein" <[email-masked]>
Date: Fri, 5 Nov 2004 19:46:38 +0200

If this seems to be a viable and accepted option, (and I realize 2 dozen
messages is not a mandate) lets look at splitting into sub teams (WGs) along
the lines of 1 / 2  and 3 / 4 so we can start closing things out for
standard status.

Eric

> > - finish the work on assisted tunneling, zeroconf tunneling, 3GPP
tunneling
> Pekka responded:

---

From: Fred Templin <[email-masked]>
Date: Tue, 9 Nov 2004 19:39:37 -0800 (PST)

Brian E Carpenter <[email-masked]> wrote:The Flow Label general rules are Proposed Standard (RFC 3697; also see
RFC 3595). However, we still need to describe specific use cases for the
Flow Label. That is the work that needs to be done, and anyone can
publish an I-D describing a use case, and ask for a BOF.
 
Brina - I have published such a I-D along with a companion errata:
 
  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt
  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-errata-04.txt
 
(see also: http://ipvlx.org for more recent updates.)
 
Would the constituency there in Washington like to have a BOF
to discuss this?
 
Fred L. Templin
[email-masked]