Subject: [v6tc] v6tc - is there life

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Tue, 16 Nov 2004 13:39:07 +0200

Hello,

as you may have heard in the IETF meeting the Internet AD (Margaret)
encouraged the WG to start working. This would be a clear indication
that the work is needed and there is enough interest. 
I would like to hear from the possible-future-wg two things:

1) Should we still work on the requirements or do the current three
requirements shape the goal enough?
(draft-ietf-v6ops-assisted-tunneling-requirements,
draft-nielsen-v6ops-3GPP-zeroconf-goals,
draft-suryanarayanan-v6ops-zeroconf-reqs)

2) Do people have proposals for solutions?

Personally, I think the three requirements documents should give us the
guidance for being able to start the solution work. I guess, the
question is more do we want to compile them into one document or do
three of them separately give the best guidance.

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Nov 2004 15:18:02 +0200 (EET)

Hi,

> draft-suryanarayanan-v6ops-zeroconf-reqs)

I'd say yes, though we shouldn't get stuck on details, and we 
shouldn't wait for the completetion of this summarization to move 
forward.

(I've actually already polled the people "behind" the existing 
documents whether they'd want to revise it, and it seems this should 
already be in some progress.)

> three of them separately give the best guidance.

Yes ;-).  We need not wait for the requirements document though.

Florent, Alain D., Karen and myself talked a bit about different 
solution approaches, and will likely be posting some rough ideas for 
the folks to give feedback on to the list within a week or so.

Jordi also ndicated he'd be updating the tunnel endpoint discovery 
documents shortly to incorporate the latest analysis and discussion.

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

---

From: Rémi Després <[email-masked]>
Date: Tue, 16 Nov 2004 15:11:27 +0100

Comment below
Rémi Després

----- Original Message ----- 
From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, November 16, 2004 12:39 PM
Subject: [v6tc] v6tc - is there life

> draft-suryanarayanan-v6ops-zeroconf-reqs)
Yes we should (but the work on solutions can start).
Imho, there are still some significant needs which are not covered yet.
(See in particular my past contribution
http://ops.ietf.org/lists/v6ops/v6ops.2004/msg01761.html )

---

From: Alain Durand <[email-masked]>
Date: Tue, 16 Nov 2004 10:21:43 -0800

> draft-suryanarayanan-v6ops-zeroconf-reqs)

I think those 3 documents have served their purpose as is, that is, 
explain
the need for the new wg, so no further work is needed on each one of 
them separately.
However, the new wg would benefit from a combined goals document,
as the above docs shared a lot in common and as we discovered the 
differences
are in the access media properties.
We should get something soon, before the end of the calendar year,
but this should not stop the work in the solution space to start.

Parallel to that, the work on the tunnel-end-point discovery goals 
should advance and integrate
the latest proposal so we can have a meaningful discussion on how to 
implement it.

> 2) Do people have proposals for solutions?

Yes, there are already severals. However, before jumping the gun and 
pushing one particular
solution, what we need to do is look at the different general avenues 
and understand
the tradeoffs in the solution space. As Pekka mentioned, some people 
have started analysis work
(follow up to what we did in San Diego) and preliminary results should 
be published
as individual submission before January 05.

	- Alain.

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Nov 2004 19:21:32 +0000

I agree with Alain.

I think the single doc should be split into

Intro
Assumptions
Requirements (all)
Scenarios (including 3gpp)

with the Scenarios stating which requirements are applicable, and whether
the requirements are may/should/must.

We shouldn't repeat the "confusion" of scattering requirements in the
scenarios text.

Tim

-- 
Tim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Nov 2004 22:33:19 +0200 (EET)

> We shouldn't repeat the "confusion" of scattering requirements in the

What would you feel about putting the scenario-specific justifications 
inside the requirements, so that the requirements would be better 
grounded in the reality?

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Wed, 17 Nov 2004 09:08:39 +0200

Hello,

in the interest of time, I would propose that a *simple* goals document
is written that comprises the requirements from all three requirements
documents. This is then used as a guideline when designing the protocol.
Also I'm a bit afraid if we start elaborated requirements/analysis/gap
analysis/etc. this project will take number of years or we don't even wg
started as we cannot show that we really need this new protocol.

Basically, I propose that we combine the current requirements to a
single document that the authors of the current document do together -
in fairly short time. Parallel to that people would submit their
protocol proposals as Internet-Drafts.

Then we just do a quick analysis on the mailing list of the protocols
vs. the requirements and choose the one that seems to be the best fit as
a *baseline* document.

After that it's just work, which is of course easy... ;)

Cheers,

Jonne.
 
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 17 Nov 2004 11:27:46 +0100

> inside the requirements, so that the requirements would be better 

I like Tim's approach above. I think that would give a easy to read and 
clear document.

- - kurtis -

---

From: Alain Durand <[email-masked]>
Date: Wed, 17 Nov 2004 09:41:14 -0800

> protocol proposals as Internet-Drafts.

This is the process I have described in my previous mail, where things
will get done in parallel. However, one should not confuse speed with 
rush,
and there are serious tradeoff to consider in the different avenues in 
the solution
space, and it is worth spending some time (a couple months at most) 
looking at them.
This, of course, should not stop people from submitting their protocol 
proposal
as individual ID.

> vs. the requirements and choose the one that seems to be the best fit 

There is no such thing as a "quick analysis on the mailing list", you 
know that.

	- Alain.

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Thu, 18 Nov 2004 21:17:17 +0200

Alain,

> This, of course, should not stop people from submitting their protocol 

I do too agree, but still a little disagree. I think we have looked at
these requirements quite long already and they should be in pretty good
shape in general. Now we just have to take out the conflicts - if any. 

Anyways, I think somebody said that in requirements work it's
(generally) better to look at the intersection of the requirements and
not the union of the requirements. This may somewhat apply here as well.

> There is no such thing as a "quick analysis on the mailing list", you 

Alain, maybe I stated too strongly my wish to do the analysis relatively
quickly and painlessly. I don't want to start another two year project
of scenarios and analysis. 

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Alain Durand <[email-masked]>
Date: Thu, 18 Nov 2004 11:42:59 -0800

> not the union of the requirements. This may somewhat apply here as 

Agree.

> of scenarios and analysis.

Agree 100%. I'm talking about a few months to understand the spectrum 
of solution better.
Let me briefly show some of the trade-off to analyze, and I really do 
not want
to start a thread now on each of them, but just show that those will be 
issues to address
in the very near future.
	- Could we live with UDP encapsulation always on?
	- Do we need mutual authentication? How strong should this be?
	  Should some of this authentication mechanism "follow-on" atfer the 
tunnel set-up phase
	  as finished?
	- Should we embed some kind of signaling in the tunnel?

	- Alain.