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

From: Cullen Jennings <[email-masked]>
Date: Sat, 9 Sep 2006 13:51:23 -0500

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.

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.

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.

Nits

In the Header on first page, needs to day updates 3261

Somewhere in draft need a describe exactly what this changes in 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.

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+5BULu9n9kWswzKDNjlYlmmc=

  update(8) base64 identity is g8WJiVEzrbYum+z2lnS3pL 
+MIhuI439gDiMCHm01fwX5D8Ft5Ib9tewLfBT9mDOUSn6wkPSWVQfqdMF/ 
QBPkpsIIROIi2sJOYBEMXZpNrhJd8/ 
uboXMl9KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko=

  update(4) base64 identity is  
AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywOUuObcwZI3qhJReZCN7y 
bMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5cD26HrmitU 
+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E=

  reinvite(6) base64 identity is  
KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gpal8ckVM2vd1zqH/ 
F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U3kGg8To/ 
6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo=

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Sep 2006 18:28:05 -0400

I finally read this version carefully. It looks good to me. I only found 
a few minor things:

* Section 1 - Terminology:

        "callee: the user that answers a call by issuing a 2xx response
         to an INVITE request."

for consistency with the definition of caller, I suggest this say:

        "callee: the user of the UA that answers a call by issuing a
         2xx response to an INVITE request."

* Section 6.2:

When sending an UPDATE or reINVITE request that changes the connected 
identity, I think it makes sense that the sender MUST include 
Required:id-change. AFAICT in all cases when a change is sent a 
Supported:id-change has already been received, so it should not be 
necessary to send a Require. But doing so could cover some cases when 
things go amiss. And the scope of a Supported header is one of those 
things that isn't well defined, so better to be safe.

* Section 6.5:

There remains an issue of whether there will in fact be an 
authentication service on the recorded route for the dialog. To ensure 
this, during dialog establishment, the presence of Supported:id-change 
could be used as a hint that an authentication service should be 
included and Record-Route.

* Section 11.1 - Normative References:

Reference [3] is out of date. This is now RFC 4474.

	Thanks,
	Paul