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

From: Shida Schubert <[email-masked]>
Date: Sun, 10 Sep 2006 23:56:05 -0700

Draft:  draft-ietf-sip-connected-identity-01
Reviewer: Shida Schubert
Review Date: 10 Sep 06
Review Deadline: 18 Sep 06
Status: Initial review 

Summary: This draft is almost ready for publication, 
 but needs some clarifications and has nits that should 
 be fixed before publication.

The requested clarifications are listed:

 - Overall
   As the draft puts so much emphasis on authenticated 
  identity that can be verified, I think it would be useful  
  to clarify the need of authentication service to provide 
  connected identity that's authenticated. 

   I would go further and possibly describe the implication 
  of what it means to receive a conneceted-identity without 
  the signature(Although security consideration explains this 
  to some detail) and  have some text illustrating how even 
  when support for "id-change" is indicated, signed 
  connected-identity may not be provided due to absence of 
  authentication service in connected domain.  

   Draft should also clarify that support for "id-change" 
  indicated by UAS does not mean sip-identity will be provided 
  in reverse direction.
 
   There is a lot of text related to the discussions that 
  took place in the mailing list, I think the draft will be 
  a lot easier to read if you can move this out or delete them.

Editorial nits:
--------------------------
 > Section 3
  - 2nd paragraph, 4th sentence.
    [Remove "clearly"] & [Change "UAS" -> "callee"]
   =OLD=
    "However, this does not necessarily clearly indicate the
     Address of Record (AoR) of the UAS."
   =NEW= 
    "However, this does not necessarily indicate the
     Address of Record (AoR) of the callee."
 
  - 4th paragraph, 3rd sentence.
     [Put comma behind "B2BUA"]

  - 5th paragraph, 4th sentence.
    [Change "not even any" -> "no"]
   =OLD=
     "In this case there is probably not even any need to 
      re-negotiate the session"
   =NEW= 
     "In this case there is probably no need to re-negotiate 
      the session"

   - 6th paragraph.
    [Rearranging the text with list]
   =OLD=
     "This document defines a mechanism for conveying the callee identity
      to a caller when a call is answered.  The same mechanism can be used
      to convey the identity of a user that replaces the caller or callee
      following a call re-arrangement such as call transfer.  In general
      the mechanism delivers connected identity, or the identity of a
      connected user.  The same mechanism can also be used to convey the
      identity of a potential callee prior to answer. 
   =NEW=
     "This document defines a mechanism for conveying connected identity, 
      or the identity of a connected user and can be used in the following 
      scenarios.
        - To convey the callee identity to a caller when a call is 
          answered.
        - To convey the identity of a user that replacese the caller or 
          callee following a call re-arrangement such as call transfer.
        - To convey the identity of a potential callee prior to answer"

> Section 4
 - 2nd paragraph, 2nd sentence.
    [Change "request's source" -> "caller"]

 - 5th paragraph, 3rd sentence.
    [Change "forwarded request" -> "forwarding request"]

> Section 5
 - 1st paragraph, 2nd sentence.
    [Add "if the domain supports sip-identity" at the end]
  =OLD=
    "A mid-dialog request is used to provide connected identity.  The UAC
     for that request inserts its identity in the From header field of the
     request and the Identity header field can be used to provide
     authentication."
  =NEW=
    "A mid-dialog request is used to provide connected identity.  The UAC
     for that request inserts its identity in the From header field of the
     request and the Identity header field can be used to provide
     authentication if the domain supports sip-identity"
 
> Section 6.1 
  - 1st paragraph, 1st sentence.
   [Change "UA that supports changes of URI in the From and To header field during
    a dialog" -> "UAC compliant to this specification"]

> Section 6.2 
  - 1st paragraph, 1st sentence.
   [Change "UA that supports changes of URI in the From and To header field during
    a dialog" -> "UAS compliant to this specification"]

  - 2nd paragraph, 1st sentence.
   [Change "id-change" -> \"id-change\"]

 Regards
  Shida Schubert

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Thu, 21 Sep 2006 20:42:18 +0100

Francois,

Thanks for your comments - see below.

Regards,

John 

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 13 September 2006 18:00
> To: Drage, Keith (Keith); [email-masked]; Elwell, John
> Subject: Review of draft-ietf-sip-connected-identity-01
> 
> Here is my review of Connected-Identity.
> 
> I believe the document is in good shape and has received 
> ample comments
> over the years 
> from the working groups...
[JRE] In fact this document has been going less than a year, although some
abortive attempts at addressing the problem date back a couple of years or
more.

> 
> 
> 
> General Comments:
> 
> - Section 6.4
> 
>   I'm not sure what is the intent of the first paragraph. Is 
> the intent
> to say that 
>   RFC 4474 MUST be used when updating connected identity, 
> which I would
> interpret as
>   mandating the usage of the Indentity and Identity-Info 
> headers? Or are
> we saying
>   that there are other requirement concerning the From header 
> itself in
> RFC 4474 that
>   must be observed? I think it needs to be clarified.
[JRE] The former is intended. I will add the following: "This will allow an
Authentication Service on the path of the mid-dialog request to insert an
Identity header field."

> 
>   My assumption is that supporting Connected-ID does NOT mandate the
> usage of Identity
>   and Identity-Info headers. Those headers are only mandatory if
> Authenticated Connected
>   Identity is desired. If this is correct, I think it needs to be
> explicitely noted (this
>   is the material in 6.5).
[JRE] Typically a UAC does not provide an Authentication Service, and
therefore does not insert an Identity header field - that is normally the
role of a proxy. Therefore for a UAC we just mandate populating the From
header field in an appropriate way to allow an Authentication Service at a
proxy to do its job. For a UAS, however, we leave it optional whether it
verifies the signature if it receives an Identity header field.
Section 6.5 is applicable only to an Authentication Service, and you cannot
be an Authentication Service (as defined in RFC 4474) unless you also
support RFC 4474. So I don't see how this can be clarified further.

> 
> 
> - Section 6.6
>   
>   This is more of a question than a request for change. Do we know of
> proxies that
>   would have problems with From/To changing in a mid-dialog 
> request? 
[JRE] I don't personally know of any, but my knowledge here is limited. Any
RFC 3261-compliant proxy will not have a problem, and the group agreed not
to continue to take account of RFC 2543-compliant proxies.
> And
> why the 
>   phrase "that record routes"? Does it make any difference?
[JRE]If a proxy does not record route, it will not receive a mid-dialog
request.

> 
> 
> 
> Editorial comments:
> 
> - Section 3
> 
>   First sentence of first paragraph: I'd change "a call and 
> its session"
> to "a session".
[JRE] I prefer to leave as is, because there is a distinction.

> 
>   Last sentence of first paragraph: I'd change "because of call
> forwarding" to "because of
>   retargeting".
[JRE] OK

> 
> 
> - Section 4
> 
>   Last paragraph: remove ", typically located at the outbound 
> proxy, ".
> It's not necessarily
>   false, but I don't think we need to say that as we can't really
> predict how this will be
>   implemented.
[JRE] OK

> 
> 
> - Section 5
> 
>   Third paragraph: I don't believe the wording about response identity
> being subject to study 
>   is appropriate for an RFC: it made sense when we were 
> developping the
> draft, but I'd rather 
>   we remove it now. Similarly, I'm not sure we should keep the wording
> about GRUU, because
>   we can't predict if GRUU will tackle or not the annonymity issue (as
> we saw in the mailing
>   list recently). My suggestion would be to remove the paragraph
> altogether. If this is 
>   not acceptable, then I'd remove all mention of GRUU, and I'd remove
> the second sentence of
>   the paragraph.
[JRE] Deleted.

> 
> 
> - Section 6.3
> 
>   This is more a question than a request for a change. What do we mean
> by using a re-INVITE 
>   instead of an UPDATE if there is "other reasons" for the re-INVITE?
> Any example? The draft
>   makes it mandatory for both ends to support UPDATE. Is this 
> because in
> some cases we
>   may want the identity change to trigger user action (to accept the
> change for example)? If
>   so, maybe we should state it. 
[JRE] Sometimes re-INVITE is needed because you want also to do an
offer-answer and you don't anticipate an immediate answer (e.g., because
user action is anticipated), or you want to solicit an offer from the UAS
(sometimes a B2BUA needs to do that). But unless you have a particular need
to do re-INVITE, you must use UPDATE.

> 
> 
> - Section 7
> 
>   Messages show bunch of "TODO" that needs to be done.
[JRE] Cullen is helping out with calculations.

> 
> 
> - Section 11.1
>   
>   Reference [3] should be replaced with RFC 4474.
[JRE] Done

> 
>   Reference [8] shouuld be updated to draft-ietf-sip-gruu-10.
[JRE] No longer applicable.