Subject: Re: [MMUSIC] draft-ietf-mmusic-kmgmt-ext-04.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 06 May 2002 02:41:41 +0300

Hi Fredrik,

I believe the question we have to answer is: when other
mechanisms/algorithms are introduced in the future, the parameters they
will have to use, will be very similar to the ones defined for MIKEY?

If this is so, defining a human-readable framework in SDP might make
sense. If not, the current opaque approach would be sensible.

Regards,

Gonzalo

"Fredrik Lindholm (ERA)" wrote:
> 
> We recently submitted a new version of the
> draft-ietf-mmusic-kmgmt-ext. In this version
> many of the comments raised in Minneapolis
> and at the mailing list are addressed.
> 
> The open issue is still, how to include the
> key management data. The main problem is
> whether to extract the key management
> protocol's (KMP) parameters from the KMP data
> and insert these in SDP/RTSP as separate
> attribute fields or whether to treat the KMP
> data as one single value.
> 
> The two approaches can be visualized as:
>    a=key-mgmt:MyKeyMgmt algorithm=aes key=... mac=...
> and
>    a=key-mgmt:MyKeyMgmt HsdjhsUYUdsjqiHSD...
> (Similar header is then also defined for RTSP)
> 
> The first approach might be appealing as almost
> each attribute is "human readable" and can be
> parsed by SDP. However, we believe that there
> are too many disadvantages with the first
> approach compared to the second.
> 
> We have tried to summarize the main problems
> (as we currently see it) with using the first
> approach. These are:
> * When a new attribute/parameter is added to the
>   KMP, this must be registered not only in the
>   KMP, but also in SDP and RTSP. I.e., changes
>   propagate through several protocols.
> * When adding another KMP, one need to map the
>   payloads normally used by the KMP to both SDP
>   and RTSP values.
> * It can increase the bandwidth consumption (how
>   much will of course depend on how the KMP
>   encoded the data normally).
> 
> We believe these problems are serious enough to
> motivate the use of the second approach, i.e.,
> include the KMP data as one single value.
> 
> Fredrik
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

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