Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

["Andrew Allen" <[e-mail]>]

Shida

 

Response below.

 

Andrew

 

From: Shida Schubert [mailto:[e-mail]] 
Sent: Friday, June 24, 2011 7:40 AM
To: Andrew Allen
Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

 

 

Hi Andrew;

 

 Thanks for your review. 

 

 My comments inline. 

 

On Jun 22, 2011, at 12:35 AM, Andrew Allen wrote:





Seems I missed the WGLC deadline by a day or so but here are the
comments from my review:

 

Section 5

 

"mp": The hi-targeted-to-URI represents a user other than the

 user associated with the Request-URI in the incoming request

  that was retargeted.

The term "user" here is confusing. Does it mean the human user (who
might have multiple AoRs/URIs which may or may not be known to the
retargeting proxy as AoRs/URIs that all map to the same human user)?
When retargeting is the proxy supposed to assess whether the new target
URI represents the same human user or not in order to determine whether
to include the "mp" parameter or not? I'm not sure what terminology
would be best but I think "user" is likely to cause confusion.

The above issue also reoccurs in section 7

 

 Your assumption is same as my understanding of this terminology as
well. 

 

 It could be an individual or it could be a corporate entity.  


[AA] So does the proxy that is doing the re-targeting need to have
definitive knowledge that the two URIs are for the same individual (or
corporate entity)? I am not convinced that a proxy will always know that
this is the case. Often call forwarding is done based on some kind of
user configuration. In some cases the user sets up the forwarding to
another URI of (owned by) the same human user but in other cases it is
not the same human user. For example I can choose to have all my calls
forwarded to some other person (such as wife, friend, or even a hotel
where I am staying). I don't know how a proxy can tell that the URI is
for the same human user or not in such circumstances.  I think this area
needs further explanation.

 

Section 15

"Entities that have not implemented this specification MUST ignore these
parameters"?  We can't make any normative requirements on entities that
have not implemented this specification! Therefore the MUST should be
removed. I think you mean to state that according to RFC 3261 and RFC
4244 entities that are not compliant with this specification will ignore
these parameters.

 

 Yes. 


[AA] OK so this will be rephrased to remove the MUST?

 

 

There is a backward compatibility concern which I think should be
addressed. With 4244bis the URI in the Request-URI is now clearly to be
included in the History-Info when the Request-URI is replaced by the
Contact address. This was not the case in RFC 4244 where in many (if not
most) implementations rewriting the request-URI with the Contact was not
considered retargeting. Some existing UA implementations may have
assumed that the last History-Info entry cannot be their own Contact
Address but will always be their AoR. For example a UA may only look at
the next highest History-Info header field from the bottom most one in
order to determine whether the call arrived as a result of forwarding or
not from within their home domain and what the URI was that it was
forwarded from. Since outside the home domain of the UA up to now the
use of History-Info has not been deterministic some UAs may have only
looked at the last couple of History-Info header fields in order to
determine what happened to the request after it arrived within their
domain. In these kinds of scenarios having a proxy now add an additional
History-Info header field (for the rewriting of the Request-URI to the
Contact) in 4244bis may break the logic of such UAs. I am not saying we
shouldn't do this but I think some text about such possible problems
with existing implementations should be indicated in the backwards
compatibility section.

 

 The definition of retargeting in RFC4244 was not clear and it is
definitely not 

defined in RFC3261, so I can understand why some may implement it the
way 

you mentioned it. Although example in RFC4244 clearly inserts contact
address 

as the History-Info. 

 

 Never the less, we will add some text with regards to this in the
backward 

compatibility section.


[AA] OK

 

Section B.1
 
In this example, the Office and Home are not the

   same AOR as sip:[e-mail], but rather different AORs that have

   been configured as alternate addresses for Bob in the proxy.  In

   other words, Office and Bob are not bound through SIP Registration

with Bob's AOR.

 

The opportunity is missed to explain here that this means that the "rc"
parameter is not added. I think it would help to understand if that was
highlighted.

 

 You are right, but Dale and Hadriel pointed the issue here with not
marking 

hi-entry, so we are likely to change these texts as we are likely to
change the 

semantics of "rc", from the looks of the discussion. 

 

 We will reflect the followings errors you found. 

 

 As for the details in call-flow B.2 and B.3, the idea is to focus only
on 

H-I so it is easier for implementors to see what gets recorded. Do you
prefer 

the extended version similar to B.1? 

 

[AA] Yes I prefer the extended version as this is consistent with the
flows in most other SIP RFCs and also with RFC 4244. At the very least
the Request-URI, History-Info, and Contact headers need to be shown as
these all interact in a meaningful way in History Info.

 

 Regards

  Shida





 

 

 

FLOW F1

 

INVITE sip:[e-mail]   should be INVITE sip:[e-mail]

	 

	 

	FLOW F5

	 

	Request-URI for the ACK looks wrong to me shouldn't it be
bob@192.0.2.4?

	 

	 

	FLOW F6

	 

	The URI in the Request-URI and the URI in the bottom most
History-Info header field are not the same (R-URI = office@192.0.2.3 and
H-I =office@192.0.2.5). These should be the same - suggest change R-URI
tooffice@192.0.2.5 so as to avoid need to change H-I in the other flows
and also since 192.0.2.3 is Alice's UA!!.

	 

	 

	FLOW F13

	 

	Again Request-URI for the ACK looks wrong to me shouldn't it
behome@192.0.2.6?

	 

	 

	Examples in B.2 and B.3 do not have the same level of detail as
in B.1 or RFC 4244.

	 

	 

	Editorials

	Last paragraph of 10.1 .2 "compenent" should be "component"

	First and 2nd paragraph of 10.3 "add an hi-index"/"adds an
hi-entry" should be "a" not "an"

	 

	Regards

	Andrew

	 

	From: [e-mail] [mailto:[e-mail]]
On Behalf OfPaul Kyzivat
	Sent: Sunday, June 05, 2011 7:34 PM
	To: SIPCORE (Session Initiation Protocol Core) WG
	Cc: [e-mail]; SIPCORE
Chairs; Robert Sparks
	Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

	 

	[as co-chair]
	
	The current editor of draft-ietf-sipcore-rfc4244bis believes
that the document has no remaining technical issues, and is ready for
evaluation. Today, we are starting a two-week working group last call
period. This last call period ends on Sunday, June 19.
	
	The latest version of the document can be retrieved here:
	
	http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis
	
	Any comments on the document should be sent to the SIPCORE
mailing list.
	
	    Thanks,
	    Paul

	
--------------------------------------------------------------------- 
	This transmission (including any attachments) may contain
confidential information, privileged material (including material
protected by the solicitor-client or other applicable privileges), or
constitute non-public information. Any use of this information by anyone
other than the intended recipient is prohibited. If you have received
this transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients is not authorized and may be
unlawful._______________________________________________
	sipcore mailing list
	[e-mail]
	https://www.ietf.org/mailman/listinfo/sipcore

 


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.