[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mumti6dt drafts as WG drafts?
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.
> 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
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
>> 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
>> Hash Based Addresses (HBA)
>> Functional decomposition of the M6 protocol
>> Failure Detection and Locator Selection in Multi6
>> Multi6 Application Referral Issues
>> multi6 co-chair