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

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

Francois,

Thanks for your comments - see below.

Regards,

John 

> -----Original Message-----
> From: Francois Audet [mailto:audet at nortel.com] 
> Sent: 13 September 2006 18:00
> To: Drage, Keith (Keith); sip at ietf.org; 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.

> 

_______________________________________________
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