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

Re: proposed new v6ops charter


On Nov 15, 2004, at 11:54 PM, Pekka Savola wrote:

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.

The experience has proven that such specific items are better covered where the clues are,
i.e. in the relevant wg and not in v6ops. Participation to those wgs by v6ops members is more likely
to get the work done (by exporting v6 clues outside of v6ops) as oppose to try to do
everything in v6ops.

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.

I do not see anything really more specific in the suggested charter either.
Saying you want to work in the "security" or "Ipv6 protocol" isn't helping much.
This is the dilemma with an Ops group working on deploying a new technology,
work is relevant when specific issues are discovered while deploying, but such
issues are unpredictable, thus difficult to put in a charter.

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.

I do not like much the idea of analyzing generic solutions in generic environment,
this is a bit like telling people how to run their network. I'd rather like to see
things like "deployment reports", explaining what has been found to work and what not.
I think the campus document is much closer to that in its spirit than
guiding "network operators and users on how to deploy IPv6 within their existing IPv4 networks"

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?

If someone want to explain meaningful environments where the current toolbox does nor work well, sure.
However if this is about stalling other meaningful work, or going into endless ratholes, I'm not sure it's worth the pain.

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.

Maybe there could be another discussion on how to get this one out of the current deadlock.

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.

Precisely. And this is what the charter should specifically mention as potential wg work items.
About specific examples, the "don't publish unreachable" draft may be resurrected in DNSops
and there is significant overlap with v6onbydefault. This is a cross-area that needs more work.

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

The exact wording to make it clearer is left as an exercise for the chairs and AD ;-)

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?

No. However, most of them are left-overs from the previous incarnation of v6ops.


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.

let's be specific, however, this is not the best place to discuss the fate of specific drafts.
The security & renumbering docs are clearly Ops issue, so is vlan usage.
Deprecating NAT-PT will be, has it has been shown to be a operational problem.
The campus & broadband docs are good "feedback, how-to" docs useful in an Ops context.
The apps doc is done, no need to talk about it
IMHO, mech-v2 would certainly be better off if it was transfered to the ipv6 wg... the pace of progress
is just amazingly slow.
And about the scenarios/analysis, I was under the impression that the work was over.

But, in a sense, all the above are legacy work items, and in most cases, in fairly advance stages.
I'm more concerned about new work items.

The two directions that require attention seems to be Mobility and v6-only networks.

There have been several mobility experiments with v4 & v6 networks, I remember for example
a draft from Carl Williams reporting results. Certainly more is needed in that area without necessarily
going through the deadly scenario/analysis/paralysis route.

The other area that require attention is IPv6 only networks, that involved translation and/or
IPv6 over IPv4 tunneling. This is the case that for many years many have considered as an
end game scenario, but apparently, it seems that such networks are being deployed today.
Again, operational feedback to root goals/requirements for potentially missing tools
are needed.

Do you think the proposed charter covers those two directions in an adequate manner?

	- Alain.