I agree that sip-media-security-requirements needs to finished quickly, 
however, I hope that it does not require agenda time at IETF 71.

With regards to Eric's comments about scope and on particular requirements:

Personally, I don't see the appendices as an important part of this 
document, but if other working group members believe the appendices are 
valuable for historical archive, then I would not object to their 
inclusion (provided that the inclusion of the appendices does not hold 
up the rest of the document).

R-ID-BINDING:
Perhaps we could reword this as:
"The media security key management protocol must enable the media 
security keys to be cryptographically bound to an identity of the endpoint."

R-RECORDING and R-TRANSCODER:
These requirements only call for a description (somewhere) of mechanisms 
to support (respectively) recording and transcoding. Personally, I think 
these are requirements. In particular, they could be satisfied by 
specifying that in environments where recording (or transcoding) is 
required, the endpoint must share its key with the recording (or 
transcoding) device. At some point in the future we can discuss whether 
there is a better approach for satisfying one (or both) of these 
requirements (and at such a point we can discuss whether there should be 
a recommended format for transferring a key to a recording device) but 
for the time being I think the requirements are reasonable and we can 
move on.

- Matt Lepinski


DRAGE, Keith (Keith) wrote:

>Well one of the issues I thought needed agenda time was yours from
>yesterday. 
>
>---------------------------------------------------------------------
>
>GENERAL COMMENTS
>I'm concerned about the apparent lack of stability of this draft.
>When this draft was originally published, it seemed to me to have two
>purposes:
>
>- To capture the BOF consensus on the important security
>  properties for an RTPSEC protocol.
>- To be a survey for the properties of
>  the various protocols compared to those requirements.
>
>The first purpose still seems useful to me, but is best served by having
>a draft that reflects that consensus published ASAP. The second purpose
>seems to me to have been sort of overtaken by events and I'm not sure
>it's still valuable.
>
>With the first purpose firmly in mind, it seems a little problematic
>that this draft has changed so much in the past 6-12 months.
>In particular:
>
>- The -02 version totally renamed all the requirements
>- I'm not convinced that all the requirements
>  introduced in -00 have WG consensus.
>
>Since there are other documents which need to reference these
>requirements, this presents a problem for them.
>
>------------------------------------------------------------------- 
>
>This seemed to be a concern about scope creep, and as it is the chairs
>that have probably allowed that creep, it is probably difficult for them
>to direct it back to where it ought to be. This is coupled with a
>concern about whether all the requirements have consensus. This seemed
>to be something that we would normally deal with in the WG session to
>see if this comment was representative on the rest of the group and
>trying to judge how to fix the problem.
>
>Note that we have absolutely no issue with resolving comments like this
>on list - if we are able to.
>
>Other input is welcome to resolve this, and please identify any specific
>requirements that you believe do not have consensus.
>
>Regards
>
>Keith
>
>  
>
>>-----Original Message-----
>>From: Eric Rescorla [mailto:[EMAIL PROTECTED] 
>>Sent: Friday, February 29, 2008 2:14 PM
>>To: DRAGE, Keith (Keith)
>>Cc: Cullen Jennings; Dean Willis; IETF SIP List
>>Subject: Re: [Sip] Revised agenda for SIP -- needs more work yet
>>
>>At Fri, 29 Feb 2008 12:00:42 +0100,
>>DRAGE, Keith (Keith) wrote:
>>    
>>
>>>Media security requirements is holding up other chartered items in 
>>>both SIP and AVT. When we considered this for inclusion, we 
>>>      
>>>
>>believed 
>>    
>>
>>>there were two items that may need agenda item. Overnight 
>>>      
>>>
>>Dean seems 
>>    
>>
>>>to have taken the time away at the moment, but I remain unconvinced 
>>>that this does not need time.
>>>
>>>This is the media-security requirements milestones:
>>>
>>>Sep 2007    Requirements for media keying to WGLC (Informational)  
>>>Nov 2007    Requirements for media keying to IESG (Informational)  
>>>
>>>Which provides the requirements for the mechanism in these charter 
>>>items in SIP.
>>>
>>>Dec 2007    Establishment of secure media sessions using 
>>>      
>>>
>>DTLS-SRTP to
>>    
>>
>>>WGLC (PS)  
>>>Feb 2008    Establishment of secure media sessions using 
>>>      
>>>
>>DTLS-SRTP to
>>    
>>
>>>IESG (PS)
>>>
>>>And these chartered items in AVT:
>>>
>>>Dec 2007    Submit in band keying mechanism for SRTP draft 
>>>      
>>>
>>for Proposed
>>    
>>
>>>Standard
>>>      
>>>
>>For what it's worth, being neither chair nor AD, I absolutely 
>>want media-security-requirements to finish and if there are 
>>significant comments on the document, I 100% endorse giving 
>>it agenda time.
>>
>>That said, based on my review and the lack of traffic on the 
>>list, my opinion is that there aren't any major issues[0], so 
>>we should declare victory and move on!
>>
>>
>>Thanks,
>>-Ekr
>>
>>[0] The only real issues I raised in my comment were:
>>    - Should we remove the survey from the appendix. I'm fine
>>      leaving it in, since I was mostly worried about it 
>>      needing constant update.
>>    - Requirement R-RECORD. I think we could just take a 
>>      straw poll on this one.
>>
>>    
>>
>_______________________________________________
>Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [EMAIL PROTECTED] for questions on current sip
>Use [EMAIL PROTECTED] for new developments on the application of sip
>
>  
>


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to