IETF89 London, UK Sunset4 Working Group Meeting mailing list: sunset4@ietf.org Co-chairs: Marc Blanchet, Wes George ======================== [Statements here are paraphrased.] Moving to WGLC on the gap analysis No one opposed Lee Howard on ipv6 support - draft-george-ipv6-support-02.txt New work- All IETF work must work with IPv6 or be version agnostic IP efforts should not be spent retrofitting features into legacy protocols 2nd part of document is to undertake a review of what has been done We should go back to every RFC since 3100 to find IPv4 specific stuff. 32 bit identifiers that are commonly populated by an IPv4 address And so we should give some guidance about what kind of identifier to use eliminate dependencies on ipv4 Are we saying the right thing? Are we the people who should be saying it? WG document? Andrew Yourchenko: can we make the default for the IETF network IPv6-only. Ted Lemon: This is not currently in your charter. Should we change the charter? I'd rather it be an IETF stream doc (personally). Marc Blanchet: This document was the origin of sunset4. The best home for this doc is here. Lee Howard: part of the difficulty with this doc is that it is recommending IETF-wide activities. How do we babysit this stuff? Doc says that someone needs to be paid. Who decides it? Ted: we have this "late surprise" problem, which is that documents typically get their heavy review at the end of the process, and I don't want to encourage another late surprise. A good question is "why doesn't this support IPv6?" And there are already mechanisms that we could leverage. And this will be a stepwise process. Marc: can the wg adopt the doc as a wg doc? Ted: charter comes first; if we can't give this to the IAB Bernie Volz: the gap analysis is a lot of work Lee: we could split the doc. But we don't want people to block ipv6 deployment Eliot: let's get this document out, and let's split out the gap analysis. Much of this is motherhood and apple pie in terms of policies. Brian: we need a gap analysis around "what's stopping you" from deploying. The problem is that the blockers are often not in our standards but what in the code. Be careful about doing just a formalistic gap analysis. Marc Blanchet: sense of the room. Can we add a milestone for this? Strong consensus Gang Chen (remotely) on Analysis of NAT64 Port Allocation Method converge 3 related drafts purpose is to get consensus on the merge There is a tradeoff between (slide 4) various allocation methods allocation process has 3 possibilities, static, dynamic, and hybrid. Wes George: draft-donnelly... has IPR on it, and so it shouldn't be the only way forward ???: What about pervasive monitoring considerations? Dan Wing: I use bzip/bzip2. How much smaller would the logs be? This stuff is highly compressable. Gang: we will report our results in the next update. Wes: you don't need to look at your existing logs that you used for this? Run existing logs through standard compression algorithms to copare. Kaname Nishizuka: many operators get help from this draft. It would be good to include the experimental procedure. Figure is not clear. Wes: why is it that MAP.4rd only uses 45% of available ports Gang: will update to state the methodology Marc Blanchet: RFC 796 (ADDRESS MAPPINGS) -> historic? Ted: IETF last call is happening now. Wes George: please participate on the list and review our documents. We may be getting to the point where either there isn't interest in the work, or that we don't have critical mass. We need more reviews. Marc: adjourned.