Re: (ngtrans) v6 considered operational

[Pekka Savola <pekkas@netcore.fi>]

A few comments on the charter/milestones.

On Wed, 14 Aug 2002, Randy Bush wrote:
> The v6ops working group will:
[...] 
> (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.

General note: I find it interesting that the standards stack documents are
outside of the charter (with the exception of item 2, which may be a bug
in the charter).  This is very probably intended (to make that work in
other w.g.'s or areas, not here).


> (7) Assume responsibility for advancing the basic IPv6 transition
>     mechanism RFCs along the standards track, if their applicability to
>     common deployment solutions is demonstrated in (6) above:
> 
>     Transition Mechanisms (RFC 2893)
>     SIIT (RFC 2765)
>     NAT-PT (RFC 2766)
>     6to4 (RFC 3056 & 3068)
> 
>     This includes updating these mechanisms, as needed, to resolve
>     problems.  In some cases, these mechanisms may be deprecated
>     (i.e. moved to Historic), if they are not found to be applicable to
>     the deployment solutions described in (6) or if serious flaws are
>     encountered that lead us to recommend against their use.

I think SIIT used as an independent mechanism (not as an algorithm) is 
dangerous and only implemented by Ericsson and should be removed, but 
that's not an issue with the charter at any rate.
         
> (8) Identify open operational or security issues with the deployment
>     solutions documented in (6) and fully document those open issues in
>     Internet-Drafts or Informational RFCs.  The v6ops group will also
>     work to find workarounds or solutions to basic, IP-level deployment
>     issues that can be solved using widely-applicable transition
>     mechanisms, such as dual-stack, tunneling or translation.
> 
>     In the event that resolution of an open issue requires the
>     standardization of an additional, widely-applicable transition
>     mechanism, the v6ops group will work with our ADs to determine
>     whether to undertake that work within v6ops.

s/our/the/.
 
> 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.

Good.

> Oct 02   Submit Transition Mechanisms (Dual Stack & 6over4) to IESG for DS

6over4 would be one example of what is not "here and now" (which was one
goal of this proposed w.g.).  Definitely not DS material.

AFAICS, you mean RFC2893 "Transition Mechanisms for IPv6 Hosts and 
Routers" when you write Dual Stack Transition Mechanism.  This is a bit 
ambiguous.

Another explanation is that you'd mean DSTM (unacceptable as it is) &
ISATAP for PS, but that's going a bit far in the typo'ing department.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords