Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-10 Comments

From: <[email-masked]>
Date: Wed, 24 Oct 2012 06:58:04 +0000

Hello,

Here is my feedback on 4244bis-10. Sorry for this late feedback but I prefer to do it now than never.

MM#1 Section 5:  In this section which is about the protocol structure, in the Privacy bullet, the new priv-value "history" is not mentioned at all whereas it is used in the example just after. Because we are in an important structure section, this lack could lead to confusion in privacy mechanism understanding. In addition, a reference to section 10.1 dedicated to Privacy should be useful.

MM#2 Section 5: In the same idea as the previous comment, the new option tag "histinfo" is not mentioned (or I missed it)

MM#3 Section 6.1: Regarding the sentence: "In the case of an initial request, except where the UAC is part of a B2BUA, there is no cache of hi-entries
   with which to populate the History-Info header field and the hi-index is set to 1 per Section 10.3."
Reading this sentence, it is not clear to me on what should/must do the UAC. I guess, because there is no cache, the UAC can (or not) insert a hi-entry based on the R-URI with an index set to 1. And if the UAC don't add the H-I, the next proxy adding a H-I would do it for 2 entries (the received R-URI and the new R-URI). Am I right? Don't you think the sentence should be more explicit?

MM#4 Section 12.1: Regarding the sentence: "The original target is determined by finding the first hi-entry tagged with "rc" and using the hi-entry referenced by the index of "rc" header field parameter as the target for determining the appropriate mailbox. >

Instead of "the first hi-entry tagged with "rc"

I would say "the first hi-entry tagged with "rc" or "mp"" in case there is no first "rc" before an "mp". Do you agree?

MM#5 Section 12.2: In the same idea as my previous comment, in the second paragraph, why only "rc" is mentioned and not "mp"? May be I missed something.

Best Regards,
Marianne Mohali

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Brett Tate <[email-masked]>
Date: Wed, 24 Oct 2012 11:38:55 +0000

> MM#3 Section 6.1: Regarding the sentence: "In the case 
> of an initial request, except where the UAC is part of 
> a B2BUA, there is no cache of hi-entries with which to 
> populate the History-Info header field and the hi-index 
> is set to 1 per Section 10.3."
> Reading this sentence, it is not clear to me on what 
> should/must do the UAC. I guess, because there is no 
> cache, the UAC can (or not) insert a hi-entry based 
> on the R-URI with an index set to 1. And if the UAC 
> don't add the H-I, the next proxy adding a H-I would 
> do it for 2 entries (the received R-URI and the new 
> R-URI). Am I right? 

The UAC must add the History-Info.

> Don't you think the sentence should be more explicit?

I had a similar comment; although I'm not sure what all makes the text ambiguous.

1) Different from RFC 4244.
2) Text split across 3 sections.
3) Section 5.1 example is non compliant.
4) Some draft-ietf-sipcore-rfc4244bis-callflows-01 examples are non compliant.

The following are the 3 draft-ietf-sipcore-rfc4244bis-10 snippets indicating that the History-Info must be added.

Section 6.1:

"When issuing a request, the UAC MUST follow the
 procedures in Section 9.2.  In the case of an initial request, except
 where the UAC is part of a B2BUA, there is no cache of hi- entries
 with which to populate the History-Info header field and the hi-index
 is set to 1 per Section 10.3."

Section 9.2:

"When sending a request, a SIP entity MUST include all the hi-entries
 from the cache that was created per Section 9.1.  In addition, the
 SIP entity MUST add a new hi-entry to the outgoing request,"

Section 16.1:

"Inclusion of hi-target-entry along with hi-index has changed from
 MAY/RECOMMEND to MUST/MUST."

---

From: <[email-masked]>
Date: Wed, 24 Oct 2012 16:18:13 +0000

Hi Brett,

If it is true that UAC MUST include the History-Info, then:
- Several call flows are not compliant in the callflow draft (3.6, 3.7 and 3.11-comment already sent)
- Why there is no "MUST" in the UAC section when initiating a request which is the most common case??! (Issuing or receiving a request is different from initiating. There is no MUST in the sentence I quoted)
- There is no backward compatibility with RFC4244 for UAC.

If it is a MUST, it MUST be written ;)
IMO, the ambiguity comes from the fact that the UAC has no cache when initiating a request.

Marianne

-----Message d'origine-----
De : Brett Tate [mailto:[email-masked]] 
Envoyé : mercredi 24 octobre 2012 13:39
À : MOHALI Marianne OLNC/OLN; [email-masked]
Objet : RE: [sipcore] draft-ietf-sipcore-rfc4244bis-10 Comments

Section 6.1:

Section 9.2:

Section 16.1:

---

From: Shida Schubert <[email-masked]>
Date: Thu, 25 Oct 2012 02:06:20 +0900

Hi Marianne;

 My comments inline..

> - Several call flows are not compliant in the callflow draft (3.6, 3.7 and 3.11-comment already sent)

 The call flows are missing the normative behavior in 4244bis and these were addressed 
by Brett already. I will fix these. 

> - Why there is no "MUST" in the UAC section when initiating a request which is the most common case??! (Issuing or receiving a request is different from initiating. There is no MUST in the sentence…

 It does.. It references section 9.2 where the normative behavior is to add 
hi-entry. Per section 9.2 as UAC has no cache when sending initial 
request it would follow the second paragraph in section 9.2.. 

"In addition, the
   SIP entity MUST add a new hi-entry to the outgoing request"

> - There is no backward compatibility with RFC4244 for UAC.

 RFC4244 can add hi-entry as specified in section 4.3.1 of the 
RFC. It's a MAY but it is not like UAC wasn't able to add hi-entry 
that the next hop (proxy) will be surprised receiving hi-entry from 
the UAC.. It should have expected it as it was allowed to add. 

> IMO, the ambiguity comes from the fact that the UAC has no cache when initiating a request.

 Do you mean the text in 9.2 is not sufficient??

 Thanks
  Shida

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore