Subject: Re: mumti6dt drafts as WG drafts?

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Dec 2004 11:52:06 +0100

Well, yes, the solution architecture draft is intended to give the
overview.

It's quite likely that when the various pieces have stabilized,
they should be combined into a more complete document. But that is
really a question for whichever WG is tasked with doing the complete
specification, so it is not a question for multi6 today. The idea now
was to get the existing drafts into a good state individually.

     Brian

Mohan Parthasarathy wrote:
> Brian,
> 
> So, the solution architecture document will come later on based on the
> WG documents i guess. What is the rationale behind having it as
> separate documents still ? Having read some of them, i felt that it might be
> good to have some of them at least merged to understand the solution
> better. For example, the first three below (shim, hba and func) can be
> merged. 
> 
> -mohan
> 
> 
>>In accordance with the consensus to proceed with the direction
>>proposed by the design team, does anyone object to the next versions
>>of the following drafts being formally adopted as WG drafts?
>>This would mean they have names like draft-ietf-multi6-*
>>
>>Please let us know this week if you object, and why.
>>
>>     Multihoming Level 3 Shim Approach
>>     (draft-nordmark-multi6dt-shim-00.txt)
>>     Hash Based Addresses (HBA)
>>     (draft-bagnulo-multi6dt-hba-00.txt)
>>     Functional decomposition of the M6 protocol
>>     (draft-bagnulo-multi6dt-functional-dec-00.txt)
>>     Failure Detection and Locator Selection in Multi6
>>     (draft-arkko-multi6dt-failure-detection-00.txt)
>>     Multi6 Application Referral Issues
>>     (draft-nordmark-multi6dt-refer-00.txt)
>>
>>
>>    Brian
>>    multi6 co-chair
>>
> 
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 1 Dec 2004 17:12:45 +0100

Hi Mohan,

> better. For example, the first three below (shim, hba and func) can be

with respect to the HBA draft, imho it would be better to separate the 
security mechanisms used form the protocol itself. I mean imho it is 
not such a good idea to hardcode the security mechanism inside the 
protocol. HBA is, at most, one of the possible security mechanisms for 
multi6 imho. there may and probably will be others. For instance it 
makes sense to support a different security mechanism based in cgas 
(only cga i mean) in order to support mobile environmets, Probably in 
the future new security mechanisms can be defined.
So making a clear distinction between the core multi6 protocol and the 
security mechanism used is good imho

makes sense?

regards, marcelo

---

From: Jari Arkko <[email-masked]>
Date: Wed, 01 Dec 2004 18:56:53 +0200

marcelo bagnulo braun wrote:

> security mechanisms used form the protocol itself. I mean imho it is not 
> such a good idea to hardcode the security mechanism inside the protocol. 
> HBA is, at most, one of the possible security mechanisms for multi6 
> imho. there may and probably will be others. For instance it makes sense 
> to support a different security mechanism based in cgas (only cga i 
> mean) in order to support mobile environmets, Probably in the future new 
> security mechanisms can be defined.

I agree with Marcelo. To put it in slightly different words,
I believe HBA is modular enough to be defined on its own.
For the shim and functional decomposition merging would
be more appropriate.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 1 Dec 2004 19:03:56 -0800

Marcelo,

I agree that merging HBA may not be a good idea. Perhaps, i should have
stayed away from examples :-) I did not realise earlier that the output of this
WG will be these 5 documents and some other group is going to figure out
producing a solution document. 

-mohan

makes sense?

regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Dec 2004 15:22:31 +0100

The comments on this didn't amount to significant objections, so
we will adopt the next versions of these drafts as WG drafts.

Authors - please tell the co-chairs what filenames you want
within draft-ietf-multi6-*, so that we can authorize them

    Brian