[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed new v6ops charter

On Mon, 15 Nov 2004, Alain Durand wrote: 
  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.


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.

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.

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.


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

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

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.

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.

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.

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.

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.

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

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