RE: Additional use cases? (Re: Plan for moving forward)

["Francois Audet" <audet@xxxxxxxxxx>]

Hi Hannes,

I just had a careful re-read, and it seems to me that the document DOES
cover all that is needed. It seems in really good shape.

I have a few minor comments:

- Section 1: It doesn't really jump out to the sip-centric reader what
  is the role of the fingerprint. Maybe a sentence or two summarizing
  it would be useful.

- Section 5 links the offer to sip-identity, but it doesn't cover the 
  delayed offer/answer case adequately. My suggestion would be to move
  section 6.4 into section 5 and cover standard offer/answer and 
  delayed offer/answer separately. I would like a better description
  of how sip-identity is used with delayed offer/answer (both with and
  without reliable provisional responses). I think putting more 
  details on this would alleviate some of the concerns expressed on the
  list by Lakshminath. Similarly, I'd like an example in section 7 for
  delayed offer/answer.

- Section 8.2: put a reference to draft-ietf-sip-sips-04

- References: update the following references

	- I-D.ietf-mmusic-comedia-tls -> RFC 4572
	- I-D.ietf-sip-identity -> RFC 4474
	- I-D.ietf-avt-rtp-framing-contrans -> RFC 4571
	- draft-ietf-mmusic-ice-13 -> draft-ietf-mmusic-ice-15
	- I-D.ietf-mmusic-kmgmt-ext -> RFC 4567
	- I-D.ietf-mmusic-sdescriptions -> RFC 4568
	- I-D.ietf-mmusic-sdp-comedia -> RFC 4145
	- I-D.ietf-tls-rfc2246-bis -> RFC 4346
	- draft-wing-media-security-requirements-00 ->
draft-wing-media-security-requirements-03
	- draft-ietf-avt-rtp-and-rtcp-mux-03 ->
draft-ietf-avt-rtp-and-rtcp-mux-05

  Add sips:
	http://tools.ietf.org/html/draft-ietf-sip-sips-04



> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@xxxxxxx] 
> Sent: Saturday, June 09, 2007 08:59
> To: Audet, Francois (SC100:3055)
> Cc: Eric Rescorla; Lakshminath Dondeti; Dan Wing; 
> ietf-rtpsec@xxxxxxx; Sam Hartman; Tim Polk; jon.peterson@xxxxxxxxxxx
> Subject: Re: Additional use cases? (Re: Plan for moving forward)
> 
> Hi Francois,
> 
> 
> Francois Audet wrote:
> > I agree with Eric.
> >
> > More on the "it doesn't matter who is the caller" stuff:
> >
> > On the RFC 4474 side, RFC 4474 allows for the sender of the 
> request to 
> > provide the identity assertion. Yes, indeed, this is the calling 
> > party.
> >
> > There is no "response" identity. However, the callee may 
> send its own 
> > request in the reverse direction to provide it's own 
> identity, as per 
> > draft-ietf-sip-connected-identity-05.txt.
> >
> > In other words, in SIP also there is no implied "direction" 
> to this, 
> > even if technically, the origin of the protocol used a 
> client/server 
> > model (as in, request/response).
> >
> > I think we'll have to write up a "high level" description 
> on how these 
> > pieces fit together.
> >   
> 
> http://tools.ietf.org/id/draft-fischl-sipping-media-dtls-02.tx
> t is meant 
> to provide how these pieces fit together. Do you think that there is 
> something missing that needs to be added?
> 
> Ciao
> Hannes
> 
>