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

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Tue, 30 Apr 2002 14:32:13 +0200

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