Re: [AVTCORE] comments on draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt

[Roni Even <[e-mail]>]

Jonathan,
I am OK with the first option.
Roni

> -----Original Message-----
> From: Jonathan Lennox [mailto:[e-mail]]
> Sent: Tuesday, July 12, 2011 10:46 PM
> To: Roni Even
> Cc: [e-mail]
> Subject: Re: comments on draft-ietf-avtcore-srtp-encrypted-header-ext-
> 00.txt
> 
> Hi, Roni --
> 
> If extensions are specified at the session level, it's straightforward
> if all the media streams are using SRTP -- the standard RFC 5285 rules
> apply.
> 
> If there's a mix of SRTP and non-SRTP media streams, either we can say
> that encrypted extension headers MUST be ignored for non-SRTP streams,
> or we can forbid specifying encrypted extension headers at the session
> level in this case.  I'm inclined towards the former, but would be fine
> with either option.
> 
> On Jul 12, 2011, at 3:07 PM, Roni Even wrote:
> 
> > Hi Jonathan,
> > I think it will be good to have some such text.
> > What about the question about using it at the session level?
> >
> > Thanks
> > Roni
> >
> >> -----Original Message-----
> >> From: Jonathan Lennox [mailto:[e-mail]]
> >> Sent: Tuesday, July 12, 2011 9:38 PM
> >> To: Roni Even
> >> Cc: [e-mail]
> >> Subject: Re: comments on draft-ietf-avtcore-srtp-encrypted-header-
> ext-
> >> 00.txt
> >>
> >> The intention is that from the point of view of an answerer that
> >> doesn't understand this spec, urn:ietf:params:rtp-hdrext:encrypt is
> >> just another unknown header extension element URI, so it will
> negotiate
> >> not to use it using the standard RFC 5285 mechanisms.
> >>
> >> It's thus also possible to offer encrypted and non-encrypted
> versions
> >> of the same header extension element, if that's acceptable for
> security
> >> reasons.
> >>
> >> I can add some explicit text explaining this in the next revision of
> >> the draft.
> >>
> >> On Jul 12, 2011, at 4:27 AM, Roni Even wrote:
> >>
> >>> Hi,
> >>> I read the draft, some comments:
> >>>
> >>> 1. I think it needs an offer answer section. We need to specify the
> >> behavior
> >>> when an offer to encrypt the header is sent and the answerer do not
> >> support
> >>> the encryption header extension. Can alternatives, one with
> >> encryption and
> >>> one without be offered.
> >>>
> >>> 2. Extmap can be a session level attribute. What about encryption,
> is
> >> it
> >>> only a media level.
> >>>
> >>> In general are the offer answer rules from RFC 5285 applicable here
> >> and how.
> >>>
> >>>
> >>> Regards
> >>> Roni Even
> >>>
> >>
> >> --
> >> Jonathan Lennox
> >> [e-mail]
> >
> >
> 
> --
> Jonathan Lennox
> [e-mail]