Subject: proposed new v6ops charter

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Nov 2004 15:46:08 +0200 (EET)

Hi,

(co-chair hat on)

Below is the proposed draft charter for v6ops (I didn't renumber the 
sections at this point) to narrow down the focus.

This is roughly the same as presented at the meeting, with a couple of 
comments/corrections:

  - clarify what "v6-in-v4 using IPsec" meant
  - shift the milestone dates forward a little bit
  - not change the statement on "all protocol work is outside of 
scope": justification being that it may make sense to give out clearly 
"the high-order bit" of what v6ops is (in principle) NOT doing 
(without rechartering)
  - not put back the applications section, as that seems to been done 
elsewhere, and the expertise is elsewhere.  This could be done as part 
of ops work as well.

The charter proposal is below, and at the following URLs.

http://netcore.fi/pekkas/ietf/temp/v6ops-dow.txt
http://netcore.fi/pekkas/ietf/temp/v6ops-dow.html (the diff)

Comments?  Suggestions?  Please try to send them within a week or so.

(hat off)
.................

[[ the most important changes:

- remove item 3 on application development and v4 dependencies
(already done)
- remove standardization of mechanisms from item 6
- remove responsibility of existing basic v6 transition mechanisms
- add new milestones and documents

existing issues still:
  - "operational/security issue" is still a blurry concept
  - should _someone_ be responsible for the protocols? [this is not
    commonplace at IETF, though]
  - the scenarios docs are still there, but they do not trigger any
    protocol work
]]

Description of Working Group:

The global deployment of IPv6 is underway, creating an IPv4/IPv6
Internet consisting of IPv4-only, IPv6-only and IPv4/IPv6 networks and
nodes.  This deployment must be properly handled to avoid the division
of the Internet into separate IPv4 and IPv6 networks while ensuring
global addressing and connectivity for all IPv4 and IPv6 nodes.

The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides guidance for
network operators on how to deploy IPv6 into existing IPv4-only
networks, as well as into new network installations.

The v6ops working group will:

1. Solicit input from network operators and users to identify
   operational or security issues with the IPv4/IPv6 Internet, and
   determine solutions or workarounds to those issues.  This includes
   identifying standards work that is needed in other IETF WGs or
   areas and working with those groups/areas to begin appropriate
   work.  These issues will be documented in Informational or BCP
   RFCs, or in Internet-Drafts.

   For example, important pieces of the Internet infrastructure
   such as DNS, SMTP and SIP have specific operational issues when
   they operate in a shared IPv4/IPv6 network. The v6ops WG will
   cooperate with the relevant areas and WGs to document those
   issues, and find protocol or operational solutions to those
   problems.

2. Provide feedback to the IPv6 WG regarding portions of the IPv6
   specifications that cause, or are likely to cause, operational
   or security concerns, and work with the IPv6 WG to resolve
   those concerns.  This feedback will be published in
   Internet-Drafts or RFCs.

4. Publish Informational or BCP RFCs that identify potential security
   risks in the operation of shared IPv4/IPv6 networks, and document
   operational practices to eliminate or mitigate those risks.  This
   work will be done in cooperation with the Security area and other
   relevant areas or working groups.

5. Publish Informational or BCP RFCs that identify and analyze solutions
   for deploying IPv6 within common network environments, such as
   ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
   Enterprise Networks, Unmanaged Networks (Home/Small Office), and
   Cellular Networks.

   These documents should serve as useful guides to network
   operators and users on how to deploy IPv6 within their existing
   IPv4 networks, as well as in new network installations.

6. Identify open operational or security issues with the deployment
   scenarios documented in (5) and fully document those open
   issues in Internet-Drafts or Informational RFCs.

IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
the groups or areas responsible for those protocols or technologies.
However, the v6ops group will provide input to those areas/groups, as
needed, and cooperate with those areas/groups in developing and
reviewing solutions to IPv6 operational and deployment problems.

Specifying any protocols or transition mechanisms is out of scope of the WG.

Goals and Milestones:

  Nov 04
 		Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG item
 		Adopt document describing issues with NAT-PT as WG item
  Dec 04
 		Adopt IPv6 Security Overview as WG item
 		Adopt IPv6 deployment using VLANs as WG item

  Jan 05
                 Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks as WG item
 		Adopt IPv6 Network Architecture Protection as WG item

  Feb 05
                 Submit IPv6-in-IPv4 Tunneling using IPsec to IESG for Info
 		Submit IPv6 deployment using VLANs as WG item

  Mar 05
                 Submit IPv6 Security Overview to IESG for Info
 		Submit document describing issues with NAT-PT to IESG for Info
  		Submit Enterprise Deployment Analysiss to IESG for Info

  Apr 05		Submit IPv6 Network Architecture Protection to IESG for Info

  May 05		Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 12 Nov 2004 10:06:42 -0500

Hi Pekka, all,

Thanks a lot for the openness in making this changes in the list. I think
this is a very important sign of moving into a good direction.

Now, get back to the work ;-)

I mostly agree with your proposed changes, but I've some concerns on number
6. I think it should stay as we have it now, because it already says that
first we will try to do that work (if required), in the most appropriate WG,
and only will be done in v6ops if there is not another option on that
direction.

Also not sure if 3 and 7 should be removed, even if the work is already
done. May be to state that this has been already accomplished ? It seems to
me that removing it is like "canceling" (or out-chartering) the work already
done, which obviously is not what we want to do, right ? Note that I'm not
opposing to this change, just will like to make sure that is the right way
to proceed.

Finally, if we accept as a WG item (which I agree), the IPv6 NAP, then we
should be fair and accept also, at least, the IPv6 Distributed Security
problem statement and requirements documents.

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Responder a: [email-masked]
> Fecha: Fri, 12 Nov 2004 15:46:08 +0200 (EET)
> Para: [email-masked]
> Asunto: proposed new v6ops charter
> 
> Hi,
> 
> (co-chair hat on)
> 
> May 05        Submit ISP IPv6 Deployment Scenarios in Broadband Access
Networks to 
> IESG for Info

**********************************
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: Pekka Savola <[email-masked]>
Date: Fri, 12 Nov 2004 17:53:05 +0200 (EET)

> and only will be done in v6ops if there is not another option on that

The point is that v6ops would, as written, just identify the issues, 
not act as a "mini-BoF" for solutions to those issues.  There are more 
generic avenues for that, and if something important comes along, 
rechartering is always possible, of course.

> opposing to this change, just will like to make sure that is the right way

Umm.  So, what you suggest would be keeping the charter as is? 3, 6 
and 7 were the sections where there were changes :).

The work that has already been accomplished is typically taken out 
from cluttering the charter, and I see no issue with that.

> problem statement and requirements documents.

IPv6 NAP is not accepted yet though there seemed to be strong support 
for it at the meeting.  Putting stuff on the milestones is no 
commitment one way or the other; especially, even if something wasn't 
in the milestones, it can still be added easily.

In the particular example you cite, the question would be whether 
those would be useful enough in this WG without a solution they call 
for, and if there is no solution, there is no sense in publishing them 
(as-is in any case).  From that perspective, I personally think these 
could form a core for a BoF to try to get those security geeks in the 
same room with v6 people who are worried about these issues.

-- 
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: Tim Chown <[email-masked]>
Date: Fri, 12 Nov 2004 16:20:57 +0000

> rechartering is always possible, of course.

Right, but I would assume drafts would be written to document the issues,
and those drafts become focuses for discussion.  An example might be the
onlink-by-default draft that Alain produced.  

Such drafts might then be published as Informational (bearing in mind Kurtis'
concern on "too many drafts"), or they could be used for the next revision
of an existing RFC, or they could just lead to modifications of a draft in 
progress in another WG, where the rationale is captured there.

In some cases the issue may not fit another WG, or an apparently appropriate
WG may not adopt the issue.   So I think we should have some valve in the
charter that does not prevent work being studied in v6ops if the WG approves
and a BoF/spin-out is not appropriate.  But I would hope that would be a
rare corner case.

I think the v6tc spin-out is working well, and I wouldn't like to see a v6ops
charter that prevented a similar spin-off in the future, so as long as the
"no mini-BoF" text allowed that, fine.

Tim

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 12 Nov 2004 13:34:42 -0500

Hi Pekka,

I didn't want to keep 3 and 7. I just wondered if it makes sense to delete
something that we did, instead of including a note as "DONE". Anyway, is not
important, probably I never noticed this when other charters had been
updated and as you say is just ok removing both. I guess also an archive of
the previous versions of the charter should be available somewhere, for
clarity.

I agree that we should only identify the issues, but identifying the issues
should be open enough to host within the WG, as WG items, those documents
that analyze those issues.

Not sure why not the WG could act, if required, as a "mini-BoF" to charter
those solutions. What it will be wrong if we do that ? There is any rational
to avoid this which I'm missing ?

For the same reason, even if we don't provide a solution, should be fine to
describe an issue. I agree that in some cases a new WG is better (via BoF or
whatever), as we decided for the v6tc, but while that process doesn't move
forward, those documents should be WG documents. Otherwise, please, just
remove from the charter all the security thing, but not decide w/o a
consensus from the WG, that of course, should agree with the charter, what
is WG item and what's not. We started to change how we manage this, right ?
;-)

Regards,
Jordi

> Fecha: Fri, 12 Nov 2004 17:53:05 +0200 (EET)
> Para: JORDI PALET MARTINEZ <[email-masked]>
> CC: [email-masked]
> Asunto: Re: proposed new v6ops charter
>

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 12 Nov 2004 20:29:03 +0100

Hi Jordi,

<snip>

>problem statement and requirements documents.
<end snip>

As Pekka mentioned, there was strong feeling during v6ops session on
'IPv6 NAP' adoption as WG item, i don't know the general feeling about
the IPv6 Distributed Security draft on the same question? It would be fair to
ask this question to the v6ops WG/chairs and check what the feeling is.

Brgds,
G/

At 10:06 12/11/2004 -0500, JORDI PALET MARTINEZ wrote:
> > Adopt document describing how to use IPsec with 
> draft-ietf-v6ops-mech-v2 as WG
> > item
>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: Pekka Savola <[email-masked]>
Date: Fri, 12 Nov 2004 23:55:42 +0200 (EET)

I'm only responding to a couple of issues because otherwise this 
seems to be getting to a rathole.  If you need more, we can discuss 
this off-list.

> the previous versions of the charter should be available somewhere, for

It is, a snapshot at the time of a meeting is included in the 
proceedings.

> to avoid this which I'm missing ?

Because one intent of a real BoF is to get together people who are 
interested in the subject (or opposed to the topic).  During it along 
the regular WG process loses that property.

---

From: Tim Chown <[email-masked]>
Date: Fri, 12 Nov 2004 22:01:18 +0000

> "the high-order bit" of what v6ops is (in principle) NOT doing 

OK, so so long as that valve is there that's good; but main focus on the
operational.

> elsewhere, and the expertise is elsewhere.  This could be done as part 

Since we have the app-aspects draft done, and the survey work done, I
agree this should be removed.   The only snag is that if app-specific 
issues arise, it's hard to say which apps WG they should be taken too.
But let's cross that bridge if/when we come to it, and leave the (identified
and done) apps work off charter.

>  - "operational/security issue" is still a blurry concept

Well, what do you see we should be doing?  And what do you plan to do
with draft-savola-v6ops-security-overview-03 for example?

>    commonplace at IETF, though]

What worries me a little is that N different WGs may (for example) devise
their own v6 tunneling methods for specific usage, where they could benefit
from a more unified approach.  Someone needs to play sweeper in the likely
groups where this sort of thing might happen, ideally before it then
emerges as an operational issue (interop, complexity, whatever).

>  - the scenarios docs are still there, but they do not trigger any

So we need to look at all four analyses (three of which are in) and check
the gaps before we close off anything firmly, I think.  The v6tc area is
one such gap.  Do we have others?

> global addressing and connectivity for all IPv4 and IPv6 nodes.

Maybe emphasises that dual-stack is the likely norm (than 6-only) and
we should focus work on that for the next 1-3 years?

>   RFCs, or in Internet-Drafts.

I think this is the main thrust.

> 2. Provide feedback to the IPv6 WG regarding portions of the IPv6
     ...

Agreed.

>   relevant areas or working groups.

I think 4 is kind of implied in 1 - maybe remove "or security" from
1 to leave it more general?
 
>   for deploying IPv6 within common network environments, such as
    ....

Agree.
 
>   issues in Internet-Drafts or Informational RFCs.

Again it kind of rehashes 1 and 4, as they stand.
 
> reviewing solutions to IPv6 operational and deployment problems.

Clearly we need to push v6 to these groups, although it is probably well
considered by most already (some feedback on which groups need a bigger
push would be useful).  You could name some specific areas, like operation
of IPv6 Multicast with transition tools.

> Specifying any protocols or transition mechanisms is out of scope of the WG.

Maybe add a line as to how/where such work would be done?
 
> 		Adopt IPv6 Security Overview as WG item

Aha, that's your -03 doc?

Agree with all four adoptions.

I think Jordi's distributed-security text should be presented in the Security
are, as per Charter item 4.
 
>  		Submit Enterprise Deployment Analysiss to IESG for Info

Can we finish this sooner?  (Indeed, if there is no noew work in Charter
from this analysis, one could wonder how urgent it actually is.... we
do seem to be handwaving away whatevcer it might conclude?)
 
-- 
Tim

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 13 Nov 2004 12:46:56 +0100

Hi Gunter,

This is my point, if we ask the question for one document, because is within
the charter, we must ask the same question for other documents if they are
also in the charter ;-)

I understand that you mean that's the fair thing to do, right ?

Regards,
Jordi

> De: "Gunter Van de Velde (gvandeve)" <[email-masked]>
> Fecha: Fri, 12 Nov 2004 20:29:03 +0100
> Para: [email-masked]
> CC: <[email-masked]>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 13 Nov 2004 12:42:28 +0100

Tim,

FYI. The IPv6 distributed security has been presented in the security area
in IETF60, has been sent to their list, inputs had been requested, etc.,
etc., etc. No reply at all !

This is my fear about what it can happen with other works if they don't fit
in v6ops and are *ignored* by other WGs that should take care of it. Is an
issue, and probably requires some "mandate" from the IESG or IAB ?

Regards,
Jordi

> De: Tim Chown <[email-masked]>
> Fecha: Fri, 12 Nov 2004 22:01:18 +0000
> Para: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Sun, 14 Nov 2004 23:30:22 +0000

> issue, and probably requires some "mandate" from the IESG or IAB ?

One argument would be that if the security folks don't want to pick it up,
there's little chance of anything in the draft being taken forward and
implemented... i.e. the danger is that v6ops would create "white elephant"
solutions that people don't want.  We need an answer to that argument...
as it stands no reply = no interest.

In contrast, the NAP draft is an architectural document that describes how
the properties of v4+NAT can be achieved in IPv6 (and has identified some
gaps, such that the internal topology obfuscation, which Gunter has promised
some further thoughts on).   As such, it's an informational text that will
be cited as a useful BCP.

Tim

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 15 Nov 2004 19:39:13 +0100

> issue, and probably requires some "mandate" from the IESG or IAB ?

As I said at the microphone in D.C, I think the issue then is to get 
the relevant groups interested rather than "let's do it anyway"....or 
maybe conclude that the particular work item (in general, not referring 
directly to you) perhaps is not interesting?

- - kurtis -

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 15 Nov 2004 21:59:06 +0100

Hi Kurtis,

Let's try to see it from another perspective.

Some people at v6ops believes is interesting and necessary to working in
topic "a". This topic fits very well in WG "x" charter, but WG "x", don't
care (may be they are not sufficiently aware about IPv6, or they have
already too much work, etc.). If the v6ops people can't convince (or they
don't have enough "participants" to be strong enough in WG "x"), this not
necessarily means that topic "a" is not interesting, right ? Is more a
question of newcomers with more work starting to participate in an existing
WG which is already busy ...

Regards,
Jordi

> De: Kurt Erik Lindqvist <[email-masked]>
> Fecha: Mon, 15 Nov 2004 19:39:13 +0100
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
> 
> iQA/AwUBQZj326arNKXTPFCVEQK42QCdEX2XMrF6rYzIgxUA+kaDdBeje8MAmQEz
> Neq+So+tVWA9+fv3m/5vC4ZC
> =8EuQ
> -----END PGP SIGNATURE-----
> 
> 
>

---

From: "EricLKlein" <[email-masked]>
Date: Mon, 15 Nov 2004 23:21:42 +0200

> JORDI
Maybe it is time that the people from V6Ops that feel this is important join
the security WG and start discussions there.
1. There is no real limit on WGs that you join, just limits on the time you
can contribute
2. Maybe if new people start talking and discussing this they will start to
understand and will start to work on it too.

Eric

---

From: Alain Durand <[email-masked]>
Date: Mon, 15 Nov 2004 21:24:06 -0800

>   RFCs, or in Internet-Drafts.

Yes.

>   issues, and find protocol or operational solutions to those

DNS IPv6 issues are well handled by DNSop, my understanding was
that one of the SIP wg is eventually talking about v4/v6 coexistence
and I'm not sure anymore about the fate of v6 SMTP.

My point is that those examples should be removed as they are NOT being
addressed by the v6OPS wg, neither in the recent past nor in the 
proposed
milestones.

>   those concerns.  This feedback will be published in

If you remove the specific examples, there is then no reason to single 
out
the IPv6 wg from the rest of the IETF.

>   relevant areas or working groups.

Again, this could be folded in 1).

>   IPv4 networks, as well as in new network installations.

I thought we were done with that.

>   issues in Internet-Drafts or Informational RFCs.

ditto.

> draft-ietf-v6ops-mech-v2 as WG item
> Networks to IESG for Info

I do not see any milestones about the work on v6onbydefault, arguably 
the few pieces
of real ops feedback that was worked on in this wg along DNS issues.

To up-level this discussion, my feedback to the chairs and the AD is 
that v6ops should focus more on ops issues.
The target of this wg should be to document in RFCs issues that came 
during deployment with suggested workaround
and/or send draft in the relevant wg when something need to be changed 
in protocol specs.

Another piece of work that is of interest is collecting feedback from 
folks doing real deployment and using
the transition toolbox we have since NGtrans. Documenting what works 
and what does not would be very valuable.

IMHO, anything else should be out of scope.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Nov 2004 09:54:22 +0200 (EET)

On Mon, 15 Nov 2004, Alain Durand wrote:
> addressed by the v6OPS wg, neither in the recent past nor in the proposed
> milestones.

Do you have further examples in mind to talk about here?  IMHO, it's 
good to have examples, and I didn't remove them (even if they were 
done) because they were illustrating which kind of issues the charter 
was referring to.

> If you remove the specific examples, there is then no reason to single out

Agreed, though the item 2 has slightly different focus as I read it. 
It seems to say, "check and keep checking the existing IPv6 
specifications that they work OK", while item 1 seems to say "identify 
missing pieces which need new work".

> Again, this could be folded in 1).

True, if item 1 is made generic -- there is a danger in too much 
genericity that one forgets which specific kinds of tasks (like 2 and 
4 here) have been put forward to the WG.

> I thought we were done with that.

What do you call the campus transition document then?  Granted the 
text in the second paragraph should be tweaked a bit to fit.

Another related document was the description of broadband ISP IPv6 
deployment efforts.

It's not like we want to do a lot more of the scenarios documents, and 
we certainly don't want to go down the analysis path, but if someone 
wants to do a document describing IPv6 deployment scenario, is there a 
good reason to rule it out?

> I do not see any milestones about the work on v6onbydefault, 
> arguably the few pieces of real ops feedback that was worked on in 
> this wg along DNS issues.

The v6onbydefault work is close to done and going forward as it is so 
there is no need to call it out here, AFAICS.

If you refer to some other potential work items relating or close to 
"v6onbydefault", feel free to suggest them.  I'd expect those are just 
ones that will come up when folks think of something.

> that v6ops should focus more on ops issues. The target of this wg 
> should be to document in RFCs issues that came during deployment 
> with suggested workaround and/or send draft in the relevant wg when 
> something need to be changed in protocol specs.

"Issues that come during deployment" can be interpreted either widely 
or narrowly.   And depending on that..

> IMHO, anything else should be out of scope.

.. is also a very generic statement, so it's not all that useful in 
practice.

To keep this practical, do you think some of those proposed 
deliverables explicitly mentioned in the draft charter would be 
inappropriate for the scope of this WG?

Or do you have suggestions for deliverables which should be more in 
scope which might help in illustrating which kind of documents you 
refer (and not refer) to?

If we project the draft charter you'd like to see to documents 
produced by this WG, or proposed to this WG, as concrete examples, 
which do you should have been or be in scope:
  - draft-ietf-v6ops-renumbering-procedure
  - draft-ietf-v6ops-6to4-security
  - draft-ietf-v6ops-application-transition
  - the scenarios documents we did
  - the analysis documents we did
  - draft-chown-v6ops-campus-transition
  - draft-larsson-v6ops-mip-scenarios
  - draft-asadullah-v6ops-bb-deployment-scenarios
  - draft-ietf-v6ops-v6onbydefault
  - draft-ietf-v6ops-mech-v2
  - draft-aoun-v6ops-natpt-deprecate
  - draft-chown-v6ops-port-scanning-implications
  - draft-chown-v6ops-renumber-thinkabout
  - draft-chown-v6ops-vlan-usage
  - draft-savola-v6ops-security-overview
  - draft-vandevelde-v6ops-nap
  - draft-tschofenig-v6ops-secure-tunnels
  - Jordi et al's distributed security work

Let's not talk too vaguely because then nobody can understand what 
each other is saying, because "let's do operational stuff" is a very 
generic statement :)

I think I hear loud and clear that you want to see documents like 
campus transition, e.g., describing how the transition mechanisms work 
or don't, and issues brought up relating to deployment, e.g., as was 
done in v6onbydefault.  I think the current draft charter is open to 
those.  But what else would you feel would be OK?  Note that if those 
would be the only kind of work to be done, the proposed deliverables 
list might look close to empty.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 16 Nov 2004 09:15:24 +0100

> WG which is already busy ...

I just fail to see what issues around IPv6 would be so special that it 
needs special treatment and can't be handled in the respective areas? 
If I come up with this really interesting security problem in IPv4, and 
the security area does show any interest at all or are too overworked, 
can I then set up the v4ops and discuss it there?

If a certain area in the IETF is overloaded or unaware of IPv6, then 
THOSE are the problems we need to address. Not pushing ahead at any 
cost somewhere else.

- - kurtis -

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Tue, 16 Nov 2004 13:32:08 +0200

Hi,

generally, I kind of agree with Kurt. Let's not duplicate work in v6ops
and hope that other people find it useful after we are done. We really
do have to address the issues that belong to a specific WG in that WG.
If the work is not taken up there, it may be that they are busy/not
interested/etc. However, we have to take into account the possibility
that we didn't understand something, too.

Cheers,

Jonne.

On Tue, 2004-11-16 at 10:15, ext Kurt Erik Lindqvist wrote:
> iQA/AwUBQZm3IaarNKXTPFCVEQIRwwCfRoRI9rt8KgfeSK7T/9fTm+7fHIIAnAmG
> M0uqzFiLogNaoWCJxoST6zfD
> =guGg
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Nov 2004 20:04:56 +0000

> done) because they were illustrating which kind of issues the charter 

I would agree to keep examples.   maybe you could cite things like multicast
with transition.   we should hint that external wg specific items will be
distilled to those wgs (dnsop, mboned, etc).
 
> missing pieces which need new work".

I would assume our main feedback is to ipv6 wg, but how much longer do we
see the ipv6 wg existing? :)
 
> 4 here) have been put forward to the WG.

I see 1 as a general statement of intent, with 4 being a specific example.
 
> text in the second paragraph should be tweaked a bit to fit.

I agree with Pekka on this one.
 
> Another related document was the description of broadband ISP IPv6 

Yes, that was good and useful.
 
> or narrowly.   And depending on that..

True, but I think that is a focus, and thus should be what point 1 says,
which actually it rather does :)

> which do you should have been or be in scope:

Good question.  Most of them.  MIP scenarios should be pushed to mip6
perhaps (or a miptrans BoF), and distributed security certainly to the
security area (as a BoF in IETF62), as should tschofenig's draft, I think.

The rest should be v6ops wg at present, as they are operational without
specific applicability to other WGs (though line items may come out of
them for other WGs, e.g. IPv6 WG for perhaps some renumbering support
requirements).

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Nov 2004 20:07:19 +0000

> THOSE are the problems we need to address. Not pushing ahead at any 

I agree with this if it's a specific issue that is applicable to another
area WG.  There is a point to which something should be pushed before its
lack of uptake should be taken as a hint... :)

Tim

---

From: Alain Durand <[email-masked]>
Date: Tue, 16 Nov 2004 21:45:34 -0800

> done) because they were illustrating which kind of issues the charter 

The experience has proven that such specific items are better covered 
where the clues are,
i.e. in the relevant wg and not in v6ops. Participation to those wgs by 
v6ops members is more likely
to get the work done (by exporting v6 clues outside of v6ops) as oppose 
to try to do
everything in v6ops.

> 4 here) have been put forward to the WG.

I do not see anything really more specific in the suggested charter 
either.
Saying you want to work in the "security" or "Ipv6 protocol" isn't 
helping much.
This is the dilemma with an Ops group working on deploying a new 
technology,
work is relevant when specific issues are discovered while deploying, 
but such
issues are unpredictable, thus difficult to put in a charter.

> text in the second paragraph should be tweaked a bit to fit.

I do not like much the idea of analyzing generic solutions in generic 
environment,
this is a bit like telling people how to run their network. I'd rather 
like to see
things like "deployment reports", explaining what has been found to 
work and what not.
I think the campus document is much closer to that in its spirit than
guiding "network operators and users on how to deploy IPv6 within their 
existing IPv4 networks"

> good reason to rule it out?

If someone want to explain meaningful environments where the current 
toolbox does nor work well, sure.
However if this is about stalling other meaningful work, or going into 
endless ratholes, I'm not sure it's worth the pain.

>> the few pieces of real ops feedback that was worked on in this wg 
>> along DNS issues.
>

Maybe there could be another discussion on how to get this one out of 
the current deadlock.

> ones that will come up when folks think of something.

Precisely. And this is what the charter should specifically mention as 
potential wg work items.
About specific examples, the "don't publish unreachable" draft may be 
resurrected in DNSops
and there is significant overlap with v6onbydefault. This is a 
cross-area that needs more work.

>> should be to document in RFCs issues that came during deployment with 
>> suggested workaround and/or send draft in the relevant wg when 

The exact wording to make it clearer is left as an exercise for the 
chairs and AD ;-)

> inappropriate for the scope of this WG?

No.  However, most of them are left-overs from the previous incarnation 
of v6ops.

> list might look close to empty.

let's be specific, however, this is not the best place to discuss the 
fate of specific drafts.
The security & renumbering docs are clearly Ops issue, so is vlan usage.
Deprecating NAT-PT will be, has it has been shown to be a operational 
problem.
The campus & broadband docs are good "feedback, how-to" docs useful in 
an Ops context.
The apps doc is done, no need to talk about it
IMHO, mech-v2 would certainly be better off if it was transfered to the 
ipv6 wg... the pace of progress
is just amazingly slow.
And about the scenarios/analysis, I was under the impression that the 
work was over.

But, in a sense, all the above are legacy work items, and in most 
cases, in fairly advance stages.
I'm more concerned about new work items.

The two directions that require attention seems to be Mobility and 
v6-only networks.

There have been several mobility experiments with v4 & v6 networks, I 
remember for example
a draft from Carl Williams reporting results. Certainly more is needed 
in that area without necessarily
going through the deadly scenario/analysis/paralysis route.

The other area that require attention is IPv6 only networks, that 
involved translation and/or
IPv6 over IPv4 tunneling. This is the case that for many years many 
have considered as an
end game scenario, but apparently, it seems that such networks are 
being deployed today.
Again, operational feedback to root goals/requirements for potentially 
missing tools
are needed.

Do you think the proposed charter covers those two directions in an 
adequate manner?

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 28 Nov 2004 10:18:15 +0200 (EET)

Hi,

(co-chair hat on)

A new version of the proposed draft charter is available.  If you have 
quick comments on it, fire away.  In particular, the first 2-3 
paragraphs could maybe be improved a bit, but I'm not sure how to do 
it without opening cans of worms.

Available at:

http://www.netcore.fi/pekkas/ietf/temp/v6ops-dow-20041124.txt
  (and below)
http://www.netcore.fi/pekkas/ietf/temp/v6ops-dow-20041124-diff.html
  (against the previous proposal)

========

addressing and connectivity for all IPv4 and IPv6 nodes.

The main focus of the v6ops WG is to look at the immediate
deployment issues; more advanced stages of deployment and transition
are a lower priority.

The goals of the v6ops working group are:

1. Solicit input from network operators and users to identify
   operational issues with the IPv4/IPv6 Internet, and
   determine solutions or workarounds to those issues.  These issues
   will be documented in Informational or BCP RFCs, or in
   Internet-Drafts.

   This work should primarily be conducted by those areas and WGs
   which are responsible and best fit to analyze these problems, but
   v6ops may also cooperate in focusing such work.

2. Publish Informational or BCP RFCs that identify potential security
   risks in the operation of shared IPv4/IPv6 networks, and document
   operational practices to eliminate or mitigate those risks.

   This work will be done in cooperation with the Security area and
   other relevant areas or working groups.

3. As a particular instance of (1) and (2), provide feedback to
   the IPv6 WG regarding portions of the IPv6 specifications that
   cause, or are likely to cause, operational or security concerns,
   and work with the IPv6 WG to resolve those concerns.  This feedback
   will be published in Internet-Drafts or RFCs.

4. Publish Informational or BCP RFCs that identify and analyze solutions
   for deploying IPv6 within common network environments, such as
   ISP Networks (including Core, HFC/Cable, DSL & Dial-up networks),
   Enterprise Networks, Unmanaged Networks (Home/Small Office), and
   Cellular Networks.

   These documents should serve as useful guides to network
   operators and users on possible ways how to deploy IPv6 within their
   existing IPv4 networks, as well as in new network installations.

   These documents should not be normative guides for IPv6 deployment,
   and the primary intent is not capture the needs for new solutions,
   but rather describe which approaches work and which do not.

IPv6 operational and deployment issues with specific protocols or
technologies (such as Applications, Transport Protocols, Routing
Protocols, DNS or Sub-IP Protocols) are the primary responsibility of
the groups or areas responsible for those protocols or technologies.
However, the v6ops WG may provide input to those areas/groups, as
needed, and cooperate with those areas/groups in reviewing solutions
to IPv6 operational and deployment problems.

Specifying any protocols or transition mechanisms is out of scope of
the WG.

Goals and Milestones:

  Nov 04	 Adopt document describing how to use IPsec with draft-ietf-v6ops-mech-v2 as WG item
  Nov 04  Adopt document describing issues with NAT-PT as WG item
  Dec 04  Adopt IPv6 Security Overview as WG item
  Dec 04  Adopt IPv6 deployment using VLANs as WG item
  Jan 05  Adopt ISP IPv6 Deployment Scenarios in Broadband Access Networks as WG item
  Jan 05  Adopt IPv6 Network Architecture Protection as WG item
  Feb 05  Ensure draft-ietf-v6ops-v6onbydefault keeps going forward for RFC publication
  Feb 05  Submit IPv6 deployment using VLANs to IESG for Info
  Mar 05  Submit document on IPsec w/ draft-ietf-v6ops-mech-v2 to IESG for Info
  Mar 05  Submit document describing issues with NAT-PT to IESG for Info
  Apr 05  Submit Enterprise Deployment Analysis to IESG for Info
  Apr 05  Submit IPv6 Network Architecture Protection to IESG for Info
  May 05  Submit IPv6 Security Overview to IESG for Info
  May 05  Submit ISP IPv6 Deployment Scenarios in Broadband Access Networks to IESG for Info
=======

(hat off)