Re: proposed new v6ops charter

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 16 Nov 2004, Alain Durand wrote:
> > 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.

Totally agree here of course.  The problem is most felt, however, in 
cases where the WG in charge or that particular technology (e.g., 
SMTP) has been closed ages ago, and possibly even the mailing list has 
been killed.

But again, do you have examples to put here?  Either of the cases 
where this work should be done elsewhere (possibly with assitance from 
v6ops), or where this could be done here?

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

I personally see little harm in creating a document which folks could 
read for guidance.  It's not a mandate, of course, but better than 
nothing. Is it useful to put out 5 documents instead of just one (one 
for different flavours of BB ISP deployment)?  I see no reason to make 
hard and fast decisions on this one way or the other.  Both kind of 
documents may be useful. (Though I'm not 100% certain how useful it is 
to publish, as RFCs, too specific documents.)

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

Yes.  I'll open a separate thread on this.

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

In the charter itself or suggested deliverables?

Suggest text? :-)

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

This seems a clear DNSOP thing which v6ops should not get entangled 
in, except for making sure folks here will make their voices heard in 
dnsop about the draft's relation to IPv6 addresses.

> > "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 ;-)

That's likely the only way to do that.  Some seem uncomfortable with 
that, though, because they see v6ops charter as potentially being 
receptive to Foo..

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

Sure, I was just asking you to apply the policy you proposed to the 
previous drafts as a thought exercise which ones would be up for 
adoption if those hadn't been published and we had the policy you've 
in mind in place.

In a way, I tried to use this tool to get some concrete idea what kind 
of policy you had in mind.  Apparently you also had a "wide" 
interpretation of operational topics, so we're on the same page.

> IMHO, mech-v2 would certainly be better off if it was transfered to 
> the ipv6 wg... the pace of progress is just amazingly slow.

Well, its past IESG evals already, and now David Kessens just needs to 
make a decision how to interpret one Steve Bellovin's comment..

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

Not sure how useful it is to report such specific results as RFCs.  It 
seems there are many considerations about mobility here, which are 
best answered outside of v6ops with sufficient mobility experience, 
e..g, the miptrans list and a potential BoF.

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

It would certainly be useful to get input from users which want to be 
designing v6-only networks why they want to do it, what issues they've 
faced, etc., but I'm not sure if there has been any of that..

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

It's generic enough to include both, and this seems to be good enough 
for me at least...  We can't hope to enumerate all the potential items 
in the charter..  If you think something should be spelled out, you 
can always suggest text.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings