On 4/13/15 4:57 PM, Fred Baker (fred) wrote: > Lee and I are reviewing the v6ops charter. I have attached a proposed > charter and diffs against the current one. Joel has not commented on > this yet, and while we have run it by the sunset4 chairs, we haven’t > gotten a reading from them. Sunset4 is relevant because possibly the > ipv4-as-a-service discussion would be better handled there. In this > email, I’m soliciting opinions in general.
not to cast aspersions in any direction in particular, but if we seem operators running such things and have cause to provide advice on them then by all means I'm fine with that here. that seems consistent with work on for example 464xlat > The charter update started with Lee feeling that the fourth bullet of > our current charter, which reads 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. > (http://datatracker.ietf.org/wg/v6ops/charter/) is largely done. We > know how to deploy IPv6. I largely agree that some victory can be declared there. > In addition, I think we need, collectively, to figure out how to get > to IPv6-only. A large issue is “so how do we connect to IPv4 content > and services from an IPv6-only network”, which is where > ipv4-as-a-service comes in. I propose adding a bullet item regarding > a road map to IPv6-only. I think we're probably front-running the community of contributors by a fair bit, but I think there are people and projects niddling around the edges even as they employ some transition mechanism for backwards compatibility. > 4. Describe an operational roadmap to IPv6-only network deployment, > with or without IPv4 delivered as an overlay or translation service. > > In my mind, that includes operational discussions of deployments and > deployment issues in IPv4-as-a-service; one possible update would be > to make that more explicit. > > In other respects, the update is mostly editorial. > > The other three tasks remain unchanged - collect operational > experience, identify operational and security risks, and turn them > over to other working groups - notably 6man. yup > Hoping for your input. Do you agree with these changes? If not, what > changes, or further changes, would you recommend? > > As to proposed milestones, I’d like to believe that > > these are done: draft-ietf-v6ops-6to4-to-historic > draft-ietf-v6ops-cidr-prefix > > we can finalize and ship these by July: > draft-ietf-v6ops-design-choices draft-ietf-v6ops-pmtud-ecmp-problem > > and these by November: draft-ietf-v6ops-siit-dc-* (would like a > deployment report for siit-dc and siit-dc-2xlat in support) (would > like one for 464xlat as well) > > On another point, Lee and I have been discussing the operational > reports we had at IETF 92, and feel that was time well spent. Those > had a common thread, which was the deployment of Softwire’s MAP-E and > MAP-T technologies in their networks. We are thinking about asking > companies deploying IPv6 in Europe, Asia, and South America to make > reports in the coming three meetings, on their IPv6 deployments and > the issues they face. Would that be of general interest? How would > you propose to tune that concept? > > > > _______________________________________________ sunset4 mailing list > [email protected] https://www.ietf.org/mailman/listinfo/sunset4 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
