Subject: RE: Feedback on proposed charter from the IESG

From: "Bound, Jim" <[email-masked]>
Date: Wed, 12 Jan 2005 11:17:30 -0500

Hi Pekka,

My responses below.  I essentially support what Tim stated and as Alain
suggested when we are done with items and no new work meets the bar we
set we enter sleep mode.  So support Tim+Alain as caveat to my inline
response. 

> Do you have suggestions for, e.g.:
>   - what classes of documents are such that we should be working on
>     (with sufficient specifity so it doesn't seem open-ended),

I believe current input is good and basically needs of the operational
community for deployment.

But I want to note what "operational community" means and maybe we need
to call that out from v6ops view very clearly:

Operational Community:

1. Providers (telco, ISPs, IXs, Mobile Greenfield to deploy 3G IMS et al
they are all different)

2. Enterprises that require operational work from within the IETF for
Enterprise operation.

3. Liaison consortias for deployment that provide v6ops via IETF
operational requirements.  Examples are IPv6 Forum, ICANN, NANOG,
Registries, ATIS www.atis.org, NCOIC www.ncoic.org, etc.

So I would like to see operational requirements defined at least for our
charter.

>   - good criteria on how to make decisions on documents that will be
>     accepted and which will not, or
>   - anything which SHOULD NOT be in the charter?

I think that is work we need to do in the WG now and should have its own
mail thread topic is my input. So won't list it in this response.

.]
> > The charter is still a bit open ended. What is really 
> missing is good 
> > criteria on how to make decisions on documents that will be 
> accepted 
> > and which will not.

Suggest you as chair begin separate mail thread as I state above for
this discussion.  It is to important to embed in this subject title is
my suggestion.

> >
> > For example, the list of proposed milestones is rather 
> extensive and 
> > we were not entirely convinced that every single document 
> on the list 
> > really needs to be worked on in the v6ops working group.
> >
> > As is not uncommon in the Operations Area, this working group will 
> > have some topics in the charter that will be somewhat open ended.
> > However, that doesn't mean that we should take on any work that has 
> > remotely something to do with the operational aspects of running an
> > ipv6 Internet network.
> >
> > Questions that come to my mind that are important to ask are:
> >
> > Is there really an audience that needs a particular 
> document (eg. not 
> > just a very specific audience but a broad group of users)? Is there 
> > expertise in the working group to work on the topic (eg. more than 
> > just a few people should have a good understanding) ? Did 
> the people 
> > that express willingness to work on a topic actually read 
> the proposed 
> > internet draft ? Are there more than a few people willing to 
> > contribute, and an even larger group to review the document ?

I think the answer to the current work to all of the above is yes both
here in v6ops and in the v6ops understanding of the operational
community.

> >
> > I hope that this helps to guide the discussion to get a solid new 
> > charter in place.

I think the IESG gave us good feedback to think about.

> 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 addressing and 
> connectivity for all IPv4 and IPv6 nodes.

I think the above needs re-wording.

Suggested replacement text:

The global deployment of IPv6 is in process. As the deployment evolves
some basic operational requirements will exist, and new operational
requirements will be learned. The IPv6 Operations Working Group is an
IETF working group to work on these operational requirements.

To scope the work for the IPv6 Operations Working Group we define and
provide examples of work within the scope of operational requirements.

[This is the mail thread discussion I suggest above to fill out the
above sentence]

Define operational community, and then criteria in that mail thread as
WG discussion.

> 
> 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.

Above replace and state: "provides operational guidance" 

Remove "network operators" our work is useful to Managers, Architects,
et al who will deploy IPv6. 

Re-write below:

The IPv6 Operations Working Group (v6ops) develops guidelines 
for the operation of a shared IPv4/IPv6 Internet and provides 
Operational guidance on how to deploy IPv6 into
existing IPv4-only networks, as well as into new network 
installations.
 
> 
> 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 would suggest this is premature if we are to have a criteria
discussion.  I think it will hold but lets check.

> 
> 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.

I think the above are useful results in response to needs to us based on
the criteria which is what is missing in our charter.

> 
> 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.

This is important to do within the IETF community of interests I agree.

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

I am not happy about this but that is fine lets move on.  I do think
authors of transition mechanism should send them to this list so they
know they exist.

> 
> 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 =================

I support all of the above being completed as work items for v6ops.

Thanks for asking,
/jim

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Jan 2005 12:30:40 +0200 (EET)

Hi,

Attached is an attempt to rephrase the charter slightly, mainly taking 
Brian's suggestion with a slight edit.  Htmlwdiff is at:
http://www.netcore.fi/pekkas/ietf/temp/v6ops-dow-20050120-diff.html

Comments?

Inline I respond to two of Jim's points I didn't apply at this point.

> Registries, ATIS www.atis.org, NCOIC www.ncoic.org, etc.

Do these need to go in charter?  I think everyone agrees on the first 
two, but the third is likely trickier, because the IETF has a formal 
liaison only with ICANN (a technical liaison group).  Obviuously, 
anyone from those consortias or forums can come and speak up in the 
mailing-list, contact the IETF in a more formal manner, etc.

> provide examples of work within the scope of operational requirements.

I'm a bit hesitant about this for a couple of reasons:
  1) people will ask, "_what_ operational requirements?",
  2) the text can be read to mean "v6ops defines operational 
requirements document(s)" which is probably undesirable, and
  3) operational requirements from operators etc. are currently a
source of where new initiatives for new work come from, not the only 
one.

Therefore I'm hesitant to writing this about operational requirements. 
Obviously, however, if operators etc. present us with _their_ 
operational requirements, the WG should take those into serious 
consideration.. but I don't see why that would need to be in the 
charter.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 22 Jan 2005 21:35:05 +0100

I radically disagree with:

"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."

We know how long takes the IETF process, so if we put in lower priority
"more advanced stages", then we are endangering the deployment. Furthermore,
where is the bar for what is advanced for you or for me ? For example, we
are now deploying IPv6-only networks. Is that advanced or not ?

Also: "1. Solicit input from network operators and users to identify", I'm
not a network operator, but do the work for some of them. So this will
actually exclude my input. Should be reworded.

Then, if we say "ISP Networks (including Core, HFC/Cable, DSL & Dial-up
networks),", we should mention all the technologies (for example PLC),
otherwise is better to just say "including Core and any kind of access
network). Right ?

If we say "Enterprise Networks, Unmanaged Networks (Home/Small Office), and
Cellular Networks.", somehow we are limiting to those scenarios. Tomorrow we
can come up with a new one. Consequently, it will be better to finish this
sentence with something like: "..., cellular networks, or other unforeseen
scenarios which may become relevant and are not covered by the previous
ones".

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 20 Jan 2005 12:30:40 +0200 (EET)
> Para: "[email-masked]" <[email-masked]>
> CC: <[email-masked]>
> Asunto: RE: Feedback on proposed charter from the IESG
> 
> Hi,
> 

**********************************
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: "EricLKlein" <[email-masked]>
Date: Sun, 23 Jan 2005 10:03:31 +0200

From: "JORDI PALET MARTINEZ"
> otherwise is better to just say "including Core and any kind of access

I would prefer phrasing like  "including Core and all types of access
networks."

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Jan 2005 08:39:36 +0200 (EET)

> are now deploying IPv6-only networks. Is that advanced or not ?

Yes, many people have been deploying IPv6-only networks for some time 
now.  But we have to try to prioritize the work somehow.  I think most 
will agree that it is more important to get dual-stack implications 
figured out before using a lot of effort to think about what issues 
IPv6-only would bring.

That said, this might be something that might change in the next 
rechartering, depending on how the work gets done.

> actually exclude my input. Should be reworded.

It doesn't say anything about excluding any input, from anywhere :-). 
It just says that this WG should go to the network operators and users 
and ask them to list their issues.  If they tell those "voluntarily", 
that's fine. If someone else tells about an issue, that's also fine.

Feel free to suggest a rewording, now or at the charter review stage 
later on.

> otherwise is better to just say "including Core and any kind of access

I removed everything in ()'s.

> scenarios which may become relevant and are not covered by the previous

This is unnecessary, because the text already says "common network 
environments, such as"; the list is not exclusive (emphasis below 
mine):

   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.

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