Subject: [v4tov6transition] Some opinions about establish a new WG

From: huang cancan <[email-masked]>
Date: Fri, 27 Aug 2010 12:46:13 +0800

hi, folks:
    As a person who have worked in telecom operator for many years, I do
appreciate the thousands of rfcs the IETF provide us and they do help us a
lot when we deploy  technologies in our network. However, I am here to argue
that is very necessary to establish a new WG which is really focus on the
operator's need and solve our problems.

    At first, I want to make it clear that what is the operator really need
when they starting v4 to v6 transition. Why I emphasize the topic of v6
transition is because this item is quite different from any other projects.
It is just like to establish a new Internet world!!!  It is definitely a
huge systematic work other than how to deploy DS-lite in the network. When
we start this project, we  first have to show our boss the migration
strategies and paths, tell him what will happen at what time and what we can
do to solve that problems step by step. When we start to do a thing we need
a road map, isn't it?  So, the real requirement of a operator to start his
tour on IPv6 transition is to work out the strategies. And this is what 6ops
cannot provide us because they say it is our own business problem. However,
hey, the business problem is the foremost problem, isn't it? Without solve
this problem, we even cannot start our tour~~~   The evidence is as below:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
How to decide the scale of the IPv6 address space we need? For example,
China telecom will have 100+ millions subscribers in the next 3 years, and
M2M service will come soon, so we should apply for /24 or shorter?
        Since IPv6 address space is large, you can start with a longer
prefix and grow. If the APNIC’s policy allows you to get a /24, you can ask
for it.

     What kind of address allocation schemes should be deployed in
enterprise networks? Provider aggregatable address, provider independent
address or local address? If PA address, how to avoid renumbering when the
enterprise network change site or provider? If PI address, how to reduce
routing table? If local address, how to make sure all of the computers can
access internet, NAT66 is a good choice or not?
     I think this is more like a business decision than technology decision.
An ISP can definitely offer service to give enterprises an IP prefix from
its own aggregate. However, some enterprise won’t like it because of the
renumber problem you mentioned by switching provider.

---------------------------------------------------------------------------------------------------------------------------------------------------------
      Well, it is not the answer we need. What we need is what length of
prefix we should apply, which is appropriate for us.  You cannot suggest
every operator that them can start a longer prefix...... What we need is:
is there any model or formula to calculate the prefix length that we need or
address architecture planning with the considerations of the subscriber
scale and increase rate? And how can operators to utilize the address bits
before /56 and after /56 to distinguish different type of service or
different metropolitan area network in order to optimize the routing or
management.
You may said it is our own business problem,depend which one we like...... I
do believe this answer can not solve the operator's problem. If 6ops
continues gave us that answer, I don't believe the final guideline 6ops
provide us will meet our requirements.
       If the so called business problem,which is the most important factor
to make a strategy, is not concerned by 6ops, can we gather some people
working in the operator who is interest about that to discuss our business
problem in another WG, in which business problem will not be ignored?

Can-can Huang

---

From: joanthan Peng <[email-masked]>
Date: Fri, 27 Aug 2010 16:34:34 +0800

Hi all,
I totally agree with Cancan opinion. In ISP's point of view, there are so
many problems we need to handle when transitioning v4 to v6, and some of
these problems may be not "very" technical, like how to do IPv6 address
planning and what elements should be considered, or in the case of China
Telecom's network, which technics should be selected to deploy to CT's
network and what elements should be considered, etc.

I think the answers for these problems are very valuable for other ISPs, and
worth our discussion.

On Fri, Aug 27, 2010 at 12:46 PM, huang cancan <[email-masked]>wrote:

>      I think this is more like a business decision than technology
> decision. An ISP can definitely offer service to give enterprises an IP
> prefix from its own aggregate. However, some enterprise won’t like it
> because of the renumber problem you mentioned by switching provider.
>
>
> You may said it is our own business problem,depend which one we like......
> I do believe this answer can not solve the operator's problem. If 6ops
>        If the so called business problem,which is the most
> important factor to make a strategy, is not concerned by 6ops, can we gather
> some people working in the operator who is interest about that to discuss
> our business problem in another WG, in which business problem will not be
> ignored?
>
> Can-can Huang
>
>
> _______________________________________________
> v4tov6transition mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v4tov6transition
>
>

---

From: Tina TSOU <[email-masked]>
Date: Fri, 27 Aug 2010 18:29:13 +0800

Hi,
Creation of a working group is subject to the conditions of RFC 2418 section 2.1 and is the responsibility of the
IESG. The participants are responsible for satisfying the conditions of 2.1.

2.1. Criteria for formation

   When determining whether it is appropriate to create a working group,
   the Area Director(s) and the IESG will consider several issues:

    - Are the issues that the working group plans to address clear and
      relevant to the Internet community?

    - Are the goals specific and reasonably achievable, and achievable
      within a reasonable time frame?

    - What are the risks and urgency of the work, to determine the level
      of effort required?

    - Do the working group's activities overlap with those of another
      working group?  If so, it may still be appropriate to create the
      working group, but this question must be considered carefully by
      the Area Directors as subdividing efforts often dilutes the
      available technical expertise.

    - Is there sufficient interest within the IETF in the working
      group's topic with enough people willing to expend the effort to
      produce the desired result (e.g., a protocol specification)?
      Working groups require considerable effort, including management
      of the working group process, editing of working group documents,
      and contributing to the document text.  IETF experience suggests
      that these roles typically cannot all be handled by one person; a
      minimum of four or five active participants in the management
      positions are typically required in addition to a minimum of one
      or two dozen people that will attend the working group meetings
      and contribute on the mailing list.  NOTE: The interest must be
      broad enough that a working group would not be seen as merely the
      activity of a single vendor.

    - Is there enough expertise within the IETF in the working group's
      topic, and are those people interested in contributing in the
      working group?

    - Does a base of interested consumers (end-users) appear to exist
      for the planned work?  Consumer interest can be measured by
      participation of end-users within the IETF process, as well as by
      less direct means.

    - Does the IETF have a reasonable role to play in the determination
      of the technology?  There are many Internet-related technologies
      that may be interesting to IETF members but in some cases the IETF
      may not be in a position to effect the course of the technology in
      the "real world".  This can happen, for example, if the technology
      is being developed by another standards body or an industry
      consortium.

    - Are all known intellectual property rights relevant to the
      proposed working group's efforts issues understood?

    - Is the proposed work plan an open IETF effort or is it an attempt
      to "bless" non-IETF technology where the effect of input from IETF
      participants may be limited?

    - Is there a good understanding of any existing work that is
      relevant to the topics that the proposed working group is to
      pursue?  This includes work within the IETF and elsewhere.

    - Do the working group's goals overlap with known work in another
      standards body, and if so is adequate liaison in place?

   Considering the above criteria, the Area Director(s), using his or
   her best judgment, will decide whether to pursue the formation of
   the group through the chartering process.

B. R.
Tina
http://tinatsou.weebly.com/index.html
  ----- Original Message ----- 
  From: joanthan Peng 
  To: [email-masked] ; IPv6 v6ops 
  Sent: Friday, August 27, 2010 4:34 PM
  Subject: Re: [v4tov6transition] Some opinions about establish a new WG

  Hi all,
  I totally agree with Cancan opinion. In ISP's point of view, there are so many problems we need to handle when transitioning v4 to v6, and some of these problems may be not "very" technical, like how to do IPv6 address planning and what elements should be considered, or in the case of China Telecom's network, which technics should be selected to deploy to CT's network and what elements should be considered, etc. 

  I think the answers for these problems are very valuable for other ISPs, and worth our discussion.

  On Fri, Aug 27, 2010 at 12:46 PM, huang cancan <[email-masked]> wrote:

    hi, folks:
        As a person who have worked in telecom operator for many years, I do appreciate the thousands of rfcs the IETF provide us and they do help us a lot when we deploy  technologies in our network. However, I am here to argue that is very necessary to establish a new WG which is really focus on the operator's need and solve our problems. 

        At first, I want to make it clear that what is the operator really need when they starting v4 to v6 transition. Why I emphasize the topic of v6 transition is because this item is quite different from any other projects. It is just like to establish a new Internet world!!!  It is definitely a huge systematic work other than how to deploy DS-lite in the network. When we start this project, we  first have to show our boss the migration strategies and paths, tell him what will happen at what time and what we can do to solve that problems step by step. When we start to do a thing we need a road map, isn't it?  So, the real requirement of a operator to start his tour on IPv6 transition is to work out the strategies. And this is what 6ops cannot provide us because they say it is our own business problem. However, hey, the business problem is the foremost problem, isn't it? Without solve this problem, we even cannot start our tour~~~   The evidence is as below:
    -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------     How to decide the scale of the IPv6 address space we need? For example, China telecom will have 100+ millions subscribers in the next 3 years, and M2M service will come soon, so we should apply for /24 or shorter?

            Since IPv6 address space is large, you can start with a longer prefix and grow. If the APNIC’s policy allows you to get a /24, you can ask for it.

         What kind of address allocation schemes should be deployed in enterprise networks? Provider aggregatable address, provider independent address or local address? If PA address, how to avoid renumbering when the enterprise network change site or provider? If PI address, how to reduce routing table? If local address, how to make sure all of the computers can access internet, NAT66 is a good choice or not?
         I think this is more like a business decision than technology decision. An ISP can definitely offer service to give enterprises an IP prefix from its own aggregate. However, some enterprise won’t like it because of the renumber problem you mentioned by switching provider. 

      ---------------------------------------------------------------------------------------------------------------------------------------------------------
          Well, it is not the answer we need. What we need is what length of prefix we should apply, which is appropriate for us.  You cannot suggest every operator that them can start a longer prefix...... What we need is: is there any model or formula to calculate the prefix length that we need or address architecture planning with the considerations of the subscriber scale and increase rate? And how can operators to utilize the address bits before /56 and after /56 to distinguish different type of service or different metropolitan area network in order to optimize the routing or management.
    You may said it is our own business problem,depend which one we like...... I do believe this answer can not solve the operator's problem. If 6ops continues gave us that answer, I don't believe the final guideline 6ops provide us will meet our requirements.
          If the so called business problem,which is the most important factor to make a strategy, is not concerned by 6ops, can we gather some people working in the operator who is interest about that to discuss our business problem in another WG, in which business problem will not be ignored?

    Can-can Huang

------------------------------------------------------------------------------

---

From: huang cancan <[email-masked]>
Date: Fri, 27 Aug 2010 21:51:26 +0800

I  answered some of the questions

On Fri, Aug 27, 2010 at 6:29 PM, Tina TSOU <[email-masked]> wrote:

>  Hi,
>  Creation of a working group is subject to the conditions of RFC 2418
> section 2.1 and is the responsibility of the
> *2.1**. Criteria for formation*
>
 //    The working group is planning to address the strategies problem when
IPv4 transit to IPv6, giving the operator the advice with the consideration
of time, network architecture, end-point, network service, network
management and operation consideration and ICP, etc. As discussed in a side
group of multiple operators and the mediator, it is very important the
migration to IPv6 is for the future stability and use of the Internet. It is
critical to the adoption of IPv6 that all network operators have a very
clear picture of how they will transition. It’s focused on operational
issues related to the final phases of transition of v4 networks to v6, i.e.
the protection of v4 applications that need to continue to be operational
for all users while the networks are gradually transitioned from v4 to v6.
The v4v6tran WG will draw upon the work of other Working Groups in the IETF
related to IPv4 to IPv6 coexistence and transition, beginning with the
general deployment models defined by v6ops and related protocol work
produced by the 6man, softwire, dhc, and behave Working Groups.

>       within a reasonable time frame?
 //Yes. Due to the urgent situation of address running out, the guideline
for network operator should be finished as quickly as possible before July,
2011. As discussed in the side group, the plan is to present the Problem
Statement I-D, the use cases documents, the framework document and one of
the migration guide documents in Sep 22 Webex meeting. And the rest of the
migration guide documents in IETF-79 meeting. If it’s a WG, these documents
will go to the IESG in this milestone.

>  //The work is urgent because the IPv4 address is exhausting every minute.
There is almost no risk for this work if the guideline for operators is
really practical and considered comprehensively.

    It might require more reviews from operators, venders, operations
experts and end users.

>       available technical expertise.
 //This question was also discussed in the side group. I only copy them
here.

1)

V6ops has not implemented item 4 in its charter and that it is better to
split the work into two WGs, to spread the workload.

"

4. Publish Informational or BCP RFCs that identify and analyze

solutions for deploying IPv6 within common network environments, such as ISP
Networks, Enterprise Networks, Unmanaged Networks (Home/Small

Office), and Cellular Networks.

"

2)I see the following text in v6ops charter:

  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.

I want to work on "more advanced stages of transition" that is out of scope
for v6ops. Some operators would like to focus on operational issues related
to the final phases of transition of v4 networks to v6, i.e. the protection
of v4 applications that need to continue to be operational for all users
while the networks are gradually transitioned from v4 to v6.

3)

As noted in its charter, v6Ops focus on deploying IPv6 in existing IPv4
networks(I read it as the same physical network).

And when it started, many transitional Technologies IETF is currently
working on did not exist (e.g., softwire based including DS-Lite, CGN44,
NAT64, etc.). We need a new WG that focus on how to deal with problems (and
then recommendations) in networks where IPv4-IPv6 co-exist, withone or more
transitional technologies deployed, and also, "on-the-move" (i.e., if one
carrier deploys DS-Lite tomorrow, it is not the end of the game, since the
carrier would move forward (e.g., how to deal with multicast, how and when
to move to IPv6-only, etc.) All these are currently not covered by v6Ops,
and if it re-chartered, the work load would easily become overwhelmed there.

    - doing this work in v6ops would distract them from the work they
are already
doing

    - this work is not within charter for v6ops and is more than a small
re-charter

    - doing the work in v6ops would make the WG too busy

> //As far as I can see the people, Management of the working group process,
> Tina Tsou, Brian Carpenter, Fred Baker.Editing of working group documents:Yiu
> Lee and many other contributors.
>
> Who will review the documents?I see friends from China Telecom, China
> Mobile,Italian Telecom, Rogers and many other venders.
>
  All of them will attend the meeting if there is no strong time conflict.

>       topic, and are those people interested in contributing in the
//There are people from Rogers, Comcast, CT, CM to contribute to the
documents.There are more experts like Fred, Brian, Alain, Ed, Jari et al.

>       participation of end-users within the IETF process, as well as by
// I don't know, can anyone give the answer?

//It was discussed in the side group, also in the Bar BoF. It is very
important the migration to IPv6 is for the future stability and use of the
Internet. It is critical to the adoption of IPv6 that all network operators
have a very clear picture of how they will transition. It’s for
operationalissues related to the final phases of transition of v4
networks to v6.

//

//It’s an open IETF effort. The v4tov6 WG will be responsible for
translating the other WG’s inputs into a series of Best Current Practice or
advisory documents describing the migration to IPv6 for specific network
scenarios.

    - Is there a good understanding of any existing work that is
      relevant to the topics that the proposed working group is to
      pursue?  This includes work within the IETF and elsewhere.
//The IETF has been developing tools for migrating to IPv6 for a decade or
more.However, many operators have not begun that migration and are unsure
how to proceed. Operators face lags in the development and activation of
IPv6 capability in endpoints, applications, and content provider sites, even
as the pool of available IPv4 global addresses nears exhaustion. A major
factor in the delays that have occurred is the lack of a business case to
migrate for a number of the actors involved. The v6ops Working Group in the
IETF has provided an overview of the available paths to IPv6 operation.
However, operators are looking for more detailed "how to" information
specifically for the transition phase, and would like it in the form of
authoritative documentation produced by an international standards body. The
v4v6tran work is responsible for taking the work of the IETF to the next
level of detail to satisfy these requirements.
    - Do the working group's goals overlap with known work in another
      standards body, and if so is adequate liaison in place?

//There is TR-187, WT-177 and WT-242 in BBF. Roberta and Dean participate in
both the related work in v4v6tran and BBF related work.

> *From:* joanthan Peng <[email-masked]>
> *To:* [email-masked] ; IPv6 v6ops <[email-masked]>
> *Sent:* Friday, August 27, 2010 4:34 PM
> *Subject:* Re: [v4tov6transition] Some opinions about establish a new WG
>
> Hi all,
>>     At first, I want to make it clear that what is the operator really
>> need when they starting v4 to v6 transition. Why I emphasize the topic of v6
>  ------------------------------
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 27 Aug 2010 07:42:27 -0700

Copying my AD. He's on the list, but I know I monitor more closely discussions I am copied on, and I suspect he does as well.

On Aug 27, 2010, at 6:51 AM, huang cancan wrote:

> //This question was also discussed in the side group. I only copy them here.
> 
> 1) V6ops has not implemented item 4 in its charter and that it is better to split the work into two WGs, to spread the workload.
> 
> " 4. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small Office), and Cellular Networks. "

You no doubt went to http://datatracker.ietf.org/wg/v6ops/charter/ to find the charter. May I request that you select "documents" on that page or (equivalent) go to http://datatracker.ietf.org/wg/v6ops/ and survey the RFCs output by the working group? It has gone to some lengths to do this.

>> 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.
> 
> I want to work on "more advanced stages of transition" that is out of scope for v6ops. Some operators would like to focus on operational issues related to the final phases of transition of v4 networks to v6, i.e. the protection of v4 applications that need to continue to be operational for all users while the networks are gradually transitioned from v4 to v6.

Let me put this in context.

When Kurtis and I took over the working group in 2004, there were quite a number of people that really wanted to talk about their favorite cool tool for helping people make the transition. There was discussion at the time of a separate working group for the purpose, and in any event v6ops was instructed to not build protocols and with respect to transition tool, to only generate requirements. That work eventually went to behave and softwire. You will hear me tell people with some regularity to take a draft to a different working group due to charter issues, and this will be the usual reason.

The continuation of IPv4 service during transition, what I call the "coexistence phase", is at this point very near term transition issue, and is the subject in part of 

http://datatracker.ietf.org/doc/draft-ietf-v6ops-incremental-cgn
http://tools.ietf.org/html/draft-ietf-v6ops-incremental-cgn
  "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", Sheng
  Jiang, Dayong Guo, Brian Carpenter, 18-Jun-10,
  <draft-ietf-v6ops-incremental-cgn-01.txt>

which will go into working group last call on 12 September. I would encourage the operators to read and comment on it. Frankly, the final phases of transition will not be about "keeping IPv4 alive" as much as "how best to turn it off".

In any event, it has been a while since we updated the charter; if the charter itself is at issue, we should discuss that. You are correct that the question is no longer, if it ever actually was actually, "how to deploy IPv6". The current phase is "coexistence" more than "deployment", and perhaps the charter needs to say that.

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 27 Aug 2010 11:15:40 -0400

I believe this mailing list is surfacing some really good information 
and has the potential to fill in a lot of blanks for network operators.  
Can-can has emphatically described some of the problems an operator 
faces and made a good case for the need for guidance.  I support 
continuing this work and as Fred and others have pointed out, it should 
certainly build upon the already large body of RFCs, active and expired 
drafts in v6ops, 6man, softwires and behave.  An annotated bibliography 
(of all the transition/coexistence docs) would help and if no one has 
one I might take a crack at that - I had done that before the behave 
interim meeting on transition scenarios, but have not kept it up to date.

It is good to have a focused discussion to pull together problem 
statements, use cases and prior work that may address them.  I don't 
have a strong opinion on creating a new WG, holding a BoF at IETF79 or 
doing the work under an existing charter such as v6ops.  I will try to 
contribute and review the work regardless of where it is done.  I hope 
we don't waste time debating logistics and organizational matters - the 
time could be better spent on the real problem and solutions.

Ed J
SRI International

---

From: Scott Brim <[email-masked]>
Date: Fri, 27 Aug 2010 11:35:49 -0400

On 08/27/2010 04:34 EDT, joanthan Peng wrote:
> Hi all,
> I totally agree with Cancan opinion. In ISP's point of view, there are
> so many problems we need to handle when transitioning v4 to v6, and some
> of these problems may be not "very" technical, like how to do IPv6
> address planning and what elements should be considered, or in the case
> of China Telecom's network, which technics should be selected to deploy
> to CT's network and what elements should be considered, etc. 

Specifically for v4/v6 transition for mobile operators, perhaps you
should consider GSMA.  GSMA focuses on clarifying and solving real-world
operations issues, as opposed to protocol development, and is launching
a v4/v6 transition work package.  Many of the world's large mobile
operators are involved in defining the work.

Scott

---

From: Fred Baker <[email-masked]>
Date: Fri, 27 Aug 2010 08:52:53 -0700

On Aug 27, 2010, at 8:15 AM, Ed Jankiewicz wrote:

> It is good to have a focused discussion to pull together problem statements, use cases and prior work that may address them.  I don't have a strong opinion on creating a new WG, holding a BoF at IETF79 or doing the work under an existing charter such as v6ops.  I will try to contribute and review the work regardless of where it is done.  I hope we don't waste time debating logistics and organizational matters - the time could be better spent on the real problem and solutions.

I'm pretty much in the same boat.

---

From: Rémi Després <[email-masked]>
Date: Fri, 27 Aug 2010 19:28:20 +0200

Hi all,

I support Tina's proposal to have a FAQ document on IPv6 deployments.
IETF is in my understanding the right place to work on official answers to these questions, in an easily readable format.

If v6ops isn't the place to do this work, and write consensus answers to ALL questions that people involved in IPv6 deployments may ask, then a new WG is IMHO the right solution.
- Answers may be pointers to other bodies.
- Questions, shouldn't be limited to Operations-and-Management considerations; they should include some customer-oriented ones.

Regards,
RD

---

From: Randy Bush <[email-masked]>
Date: Sat, 28 Aug 2010 06:52:16 +0900

> If v6ops isn't the place to do this work, and write consensus answers
> to ALL questions that people involved in IPv6 deployments may ask

then why the heck would v6ops exist?

randy

---

From: Rémi Després <[email-masked]>
Date: Sat, 28 Aug 2010 08:00:44 +0200

> then why the heck would v6ops exist?

Whether v6ops is the place not only for OAM questions, but ALSO for customer and product-vendor considerations, is IMHO still unclear.
Making official where the work on a comprehensive and easily readable FAQ-document may start would be welcome.

RD

---

From: Ronald Bonica <[email-masked]>
Date: Sat, 28 Aug 2010 17:11:45 -0400

Fred,

I am monitoring the conversation, but have been a bit slow responding to email. For the last two days I have been distracted, delivering both of my kids to college. 

                                              Ron

> -----Original Message-----
> From: [email-masked] [mailto:v4tov6transition-
> [email-masked]] On Behalf Of Fred Baker
> Sent: Friday, August 27, 2010 10:42 AM
> To: huang cancan
> Cc: IPv6 v6ops; Ron Bonica; [email-masked]
> Copying my AD. He's on the list, but I know I monitor more closely
> discussions I am copied on, and I suspect he does as well.
> 
> > 1) V6ops has not implemented item 4 in its charter and that it is
> better to split the work into two WGs, to spread the workload.
> >
> > " 4. Publish Informational or BCP RFCs that identify and analyze
> solutions for deploying IPv6 within common network environments, such
> as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small
> Office), and Cellular Networks. "
> 
> You no doubt went to http://datatracker.ietf.org/wg/v6ops/charter/ to
> find the charter. May I request that you select "documents" on that
> page or (equivalent) go to http://datatracker.ietf.org/wg/v6ops/ and
> survey the RFCs output by the working group? It has gone to some
> lengths to do this.
> 
> deployment issues; more advanced stages of deployment and transition
> are a lower priority.
> >
> > I want to work on "more advanced stages of transition" that is out of
> scope for v6ops. Some operators would like to focus on operational
> issues related to the final phases of transition of v4 networks to v6,
> i.e. the protection of v4 applications that need to continue to be
> operational for all users while the networks are gradually transitioned
> from v4 to v6.
> 
> When Kurtis and I took over the working group in 2004, there were quite
> a number of people that really wanted to talk about their favorite cool
> tool for helping people make the transition. There was discussion at
> the time of a separate working group for the purpose, and in any event
> v6ops was instructed to not build protocols and with respect to
> transition tool, to only generate requirements. That work eventually
> went to behave and softwire. You will hear me tell people with some
> regularity to take a draft to a different working group due to charter
> issues, and this will be the usual reason.
> 
> The continuation of IPv4 service during transition, what I call the
> "coexistence phase", is at this point very near term transition issue,
> and is the subject in part of
> 
> which will go into working group last call on 12 September. I would
> encourage the operators to read and comment on it. Frankly, the final
> phases of transition will not be about "keeping IPv4 alive" as much as
> "how best to turn it off".
> 
> In any event, it has been a while since we updated the charter; if the
> charter itself is at issue, we should discuss that. You are correct
> that the question is no longer, if it ever actually was actually, "how
> to deploy IPv6". The current phase is "coexistence" more than
> "deployment", and perhaps the charter needs to say that.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 29 Aug 2010 10:53:34 -0700

On 8/27/10 11:00 PM, Rémi Després wrote:
>>> If v6ops isn't the place to do this work, and write consensus
>>> answers to ALL questions that people involved in IPv6 deployments
>>> may ask
>> 
> Whether v6ops is the place not only for OAM questions, but ALSO for
> customer and product-vendor considerations, is IMHO still unclear. 

I'll just leave items 1 and 4 from the v6ops charter here:

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.

4. Publish Informational or BCP RFCs that identify and analyze
solutions
for deploying IPv6 within common network environments, such as
ISP Networks, Enterprise Networks, Unmanaged Networks (Home/Small
Office), and Cellular Networks.

Regarding a comprehensive FAQ

I'm not an encyclopedist

(http://en.wikipedia.org/wiki/Encyclop%C3%A9die)

but I have some experience with shepherding large documents through the
ietf, and I will say that large interdependant document series can be
challenging to get through the process in a timely fashion, get proper
review on and or build consenus for. and thus I tend to favor dsicrete
documents.

Randy and Lucy built a lovely wiki for the purpose of generating a faq
something like 2 years ago, which had more than few contributors from
this community. there are limits as to the utility of a faq without
regular updates.

---

From: Ronald Bonica <[email-masked]>
Date: Sun, 29 Aug 2010 20:55:52 -0400

Tina,

It appears that there are two distinct issues being debated here. These are:

-          Is there interesting work to be done?

-          Do we need a new WG in which to do this work?

The IETF has procedures to address both questions. In order to determine the answer to the first question, the DT should submit its problem statement, framework and (possibly) an annotated bibliography to the v6ops wg. They are clearly within the charter of the v6ops and the v6ops chairs have indicated a willingness to entertain these drafts. If the wg adopts and progresses this drafts, the framework will be set for subsequent drafts.

At this time, I don't see any need for a new WG. The operational expertise that we need to review these documents lives in v6 ops, and if we were to spin off an new working group, it would probably be populated by the same people who populate v6ops today. However, I will keep a eye on this situation to see if it changes.

                                                                                         Your friendly AD,
                                                                                             Ron

---

From: Rémi Després <[email-masked]>
Date: Mon, 30 Aug 2010 10:19:35 +0200

Hi Joel,

Thanks for your reaction,
Further comments below.

> will be documented in Informational or BCP RFCs, or in

Limited to "Operational issues".

This doesn't include, in my understanding, questions like
"Are there reasons for users to ask for IPv6, in addition to IPv4, if their providers continues to offer IPv4 (be it across cascades of NATs? If yes, what are these reasons?"
"What are the security implications for a user of e-mail and of the web, with one of the main OSes, if it has IPv6 enabled?" 
Permitting v6ops, or a new group, to provide simple answers to such questions would IMHO facilitate IPv6 deployment.

> Regarding a comprehensive FAQ

Neither am I.
I just noted that, on many subjects, FAQ answers are very convenient.

> this community.

> there are limits as to the utility of a faq without
> regular updates.

Same view here.
One update per year, for example, could be a reasonable target.
A reader-friendly way to number successive versions shouldn't be difficult to adopt (RFC 99nnnn for version nnnn, or RFCxxxx-nnnn, are examples of what could be done if there is the will).
A different production and approval procedure than that of other RFCs isn't needed.

Regards,
RD