[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed new v6ops charter
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 <tjc@ecs.soton.ac.uk>
> Responder a: owner-v6ops@ops.ietf.org
> Fecha: Fri, 12 Nov 2004 22:01:18 +0000
> Para: v6ops@ops.ietf.org
> Asunto: Re: proposed new v6ops charter
>
> On Fri, Nov 12, 2004 at 03:46:08PM +0200, Pekka Savola wrote:
>>
>> - 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)
>
> OK, so so long as that valve is there that's good; but main focus on the
> operational.
>
>> - 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.
>
> 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?
>
>> - should _someone_ be responsible for the protocols? [this is not
>> 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
>> protocol work
>
> 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?
>
>> 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.
>
> 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?
>
>> 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.
>
> I think this is the main thrust.
>
>> 2. Provide feedback to the IPv6 WG regarding portions of the IPv6
> ...
>
> Agreed.
>
>> 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.
>
> I think 4 is kind of implied in 1 - maybe remove "or security" from
> 1 to leave it more general?
>
>> 5. Publish Informational or BCP RFCs that identify and analyze solutions
>> for deploying IPv6 within common network environments, such as
> ....
>
> Agree.
>
>> 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.
>
> Again it kind of rehashes 1 and 4, as they stand.
>
>> 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.
>
> 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.
>
>> Mar 05
>> 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
>
>
**********************************
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.