[Sip] RE: draft-ietf-sip-connected-identity-01 comments

["Elwell, John" <john.elwell at siemens.com>]

Cullen,

Thanks for your review. See below. Also others should take a look at the
first point below in particular.

John 

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy at cisco.com] 
> Sent: 09 September 2006 19:51
> To: SIP; Elwell, John
> Subject: draft-ietf-sip-connected-identity-01 comments
> 
> 
> John thanks for the work on this - it is looking really good and I  
> like how you have solved the issues. WIth my AD hat on, I 
> really like  
> how this draft it going and looks good. The rest of the comments are  
> sent with  my individual hat on and some of them are far more nit  
> picky that I would feel was appropriate for an IESG comment.
> 
> Few things ....
> 
> When an Update is sent. Are there any conditions under which 
> it might  
> be rejected. Bad identity for example. I think that might need a  
> little discussion and also what the UA does when it sends an update  
> with a no identity and it gets rejected.
[JRE] A very good point. We don't want to get to a situation where it is
impossible to perform a mid-dialog request (e.g., for purposes such as
session timer refresh or session re-negotiation) just because  connected
identity fails. My proposed fix is as follows:
1. Say that a UAS SHOULD NOT reject a mid-dialog request with 428 'Use
Identity Header'.
2. Say that an Authentication Service MUST NOT add an Identity header field
to a mid-dialog request if a previous request on that dialog has resulted in
436 'Bad Identity-Info', 437 'Unsupported Certificate' or 438 'Invalid
Identity Header'.
3. Say that a UAC MUST repeat a mid-dialog request that results in one of
these responses if the mid-dialog request was not solely for the purpose of
connected identity. If solely for the purpose of connected identity there is
no point in repeating it, so I will say "SHOULD NOT take any further
action".
Comments?

> 
> There is a lot of background information about how we got to this  
> decision, other ways that one might do this etc. If this was 
> moved to  
> an appendix, it would probably help implementers focus on the 
> key stuff.
[JRE]OK, I bow to pressure - a couple of others have made similar comments.
Essentially I have moved sections 3 (existing mechanisms for conveying
identity) and 4 (existing mechanisms for authenticated identity) to an
appendix.

> 
> The security section could probably use more work around the 
> issue of  
> what you can trust here and what you can't. Might want to reference  
> history as a possible solution to some of the stuff that this does  
> not solve.
[JRE] I have referenced history-info and also added something about the
possibility of terminating the call if a UA is really not happy with the
absence of a valid Identity header.

> 
> 
> Nits
> 
> In the Header on first page, needs to day updates 3261
> 
> Somewhere in draft need a describe exactly what this changes in 3261
[JRE] I thought this was covered in the existing section 5, but I have
enhanced it slightly. It now says: "This document therefore deprecates
mandatory reflection of the original To and From URIs in mid-dialog requests
and their responses, which constitutes a change to RFC 3261."

> 
> The name of the option tag "id-change" sort of bugs me. What is  
> allowed to change here does not really have to do with identity as  
> much as the from URI. I would prefer the name "from-change" as what  
> this is saying is only that part of 2543 was not required by the UA.
[JRE] Well, the URI is the identity, so I don't really understand your
point. It was changed to "id-change" from something rather longer a draft or
so back, so I would be reluctant to change it again. Any other opinions?

> 
> I computed the Identity Strings - I have a program to do this 
> and can  
> update if the messages change. Make sure we regenerate and check  
> these in in Auth 48.
> 
>   invite(2) base64 identity is xN6gCHR6KxGM 
> +nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G 
> +VwY13uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/ 
> fFGBrpBSjztmfffLTp6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzK
> DNjlYlmmc=
> 
>   update(8) base64 identity is g8WJiVEzrbYum+z2lnS3pL 
> +MIhuI439gDiMCHm01fwX5D8Ft5Ib9tewLfBT9mDOUSn6wkPSWVQfqdMF/ 
> QBPkpsIIROIi2sJOYBEMXZpNrhJd8/ 
> uboXMl9KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko=
> 
>   update(4) base64 identity is  
> AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywOUuObcwZI3
> qhJReZCN7y 
> bMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5cD26HrmitU 
> +OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E=
> 
>   reinvite(6) base64 identity is  
> KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gpal8ckVM2vd1zqH/ 
> F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U3kGg8To/ 
> 6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo=
[JRE] Thanks. The examples have not changed during WGLC, so these are still
valid, but we should check them during Auth48.
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip