Subject: [cuss] Comments on reqs-01

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Dec 2010 12:03:26 +0100

1. In Abstract it says:
"This application may have information that needs to be
   transported between the SIP User Agents during session establishment."
Also in section 1 it says:
"It is
   assumed that the application is running in both the originator of the
   session and the terminator of the session.  That is, the application
   interacts with the User Agent Client (UAC) and User Agent Server
   (UAS)."

The redirection use case in 3.3 seems to fall outside the scope of what is stated above.

2.    "REQ-2: The mechanism will allow UAs to insert and receive UUI data in
   SIP dialog terminating requests and responses."
This seems too general, e.g., it could apply to termination of a SUBSCRIBE-initiated dialog, which I don't think is intended. Shouldn't it say "call terminating requests and responses"?

3. I don't see any statement about the ability of multiple applications each to insert their own UUI in a SIP request or response. Perhaps that is considered a non-requirement, but at least we should say something on the subject. If it is required, how does REQ-11 on maximum size of UUI apply - per application or in total?

4. Relating to the previous comment, we have REQ-4 that says UUI must survive redirection, and REQ-3 that says UUI can be inserted when redirecting. How do these interact? For example, if UUI is included by the UAC in an INVITE request, and that is redirected, the redirect server is, according to REQ-4, required to preserve that UUI, but can it also insert its own UUI? If so, do the two need to be distinguishable?

5. Proxy retargeting and redirection are two SIP mechanism for achieving retargeting. Yet in one case we specifically permit UUI to be inserted at that point, and in the other case we don't. This seems to be inconsistent.

6. In section 5: "The security requirements for the SIP UUI mechanism are described in
   REQ-13 and REQ-14, providing integrity protection and/or privacy.  In
   addition, there is an identity requirement in REQ-12, which relates
   to the ability for the UAS to know who inserted the UUI."
This fails to say anything about authentication, i.e., there is a requirement to indicate which entity inserted UUI, but no requirement concerning authentication of that entity. I am not necessarily suggesting we need a new requirement (we would rely on existing SIP mechanisms), but we should at least discuss the topic.

John

---

From: Alan Johnston <[email-masked]>
Date: Mon, 20 Dec 2010 07:47:31 -0600

John,

Thanks for your comments on the draft. See below for my responses.

- Alan -

> The redirection use case in 3.3 seems to fall outside the scope of what is stated above.

The definition in the abstract is still, strictly speaking, accurate
for redirection - the UUI is between two UAs, but one of them is a
UAS.  The Section 1 definition needs clarification.  How about:

   Usually the application is running in both the originator of the
   session and the terminator of the session.  That is, the application
   interacts with the User Agent Client (UAC) and User Agent Server
   (UAS).  In the case of SIP redirection, this is modified slightly in that the
   application is running in the UAS which redirected the INVITE and
   the terminator of the session.

> This seems too general, e.g., it could apply to termination of a SUBSCRIBE-initiated dialog, which I don't think is intended. Shouldn't it say "call terminating requests and responses"?

How about:

   REQ-2: The mechanism will allow UAs to insert and receive UUI data in
   SIP call terminating requests and responses.

>
> 3. I don't see any statement about the ability of multiple applications each to insert their own UUI in a SIP request or response. Perhaps that is considered a non-requirement, but at least we should say something on the subject.

This depends on the application.  For the ISDN usage, this is not
permitted.  For other new SIP usages it could be permitted.  I don't
think we need to say anything here about this.

If it is required, how does REQ-11 on maximum size of UUI apply - per
application or in total?

Well, REQ-11 is a minimum size of UUI, not maximum, so it doesn't apply here.

> 4. Relating to the previous comment, we have REQ-4 that says UUI must survive redirection, and REQ-3 that says UUI can be inserted when redirecting. How do these interact? For example, if UUI is in…

We definitely need rules for this.  I think these rules are specific
to the mechanism, and may also be specific to the using application.

I don't think we need any more text in this requirements document about this.

> 5. Proxy retargeting and redirection are two SIP mechanism for achieving retargeting. Yet in one case we specifically permit UUI to be inserted at that point, and in the other case we don't. This s…

Well, the SIP handling of proxy retargeting and UAS redirection are
very different - one has proxy rules the other has UA rules per RFC
326`. I don't think we can or should change basic SIP rules in this
extension.  It is true that proxies can (under limited conditions per
RFC 3261 which are often ignored, I think) recurse on a redirection,
making this transparent to a UA.  However, if there are issues with
this, they need to be dealt with in SIPCORE.

> This fails to say anything about authentication, i.e., there is a requirement to indicate which entity inserted UUI, but no requirement concerning authentication of that entity. I am not necessaril…

How about:

   REQ-12: The recipient of UUI will be able to identify and
authenticate the entity
   that inserted the UUI.  It is acceptable that this is performed
   implicitly where it is known that there is only one other end UA
   involved in the dialog.  Where that does not exist, some other
   mechanism will need to be provided.

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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Dec 2010 16:08:19 +0100

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]] 
> Sent: 20 December 2010 13:48
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [cuss] Comments on reqs-01
> 
> John,
> 
[JRE] Yes, that reflects the remainder of the document better.

> > This seems too general, e.g., it could apply to termination 
> of a SUBSCRIBE-initiated dialog, which I don't think is 
> intended. Shouldn't it say "call terminating requests and responses"?
> 
> How about:
> 
[JRE] Yes, that was what I meant.

> >
> > 3. I don't see any statement about the ability of multiple 
> applications each to insert their own UUI in a SIP request or 
> response. Perhaps that is considered a non-requirement, but 
> at least we should say something on the subject.
> 
[JRE] Perhaps not, but we will have to address it in the mechanism. However, if an entity can receive two or more UUIs in the same call control message, do we need any requirement concerning the ability to distinguish them?

> Well, REQ-11 is a minimum size of UUI, not maximum, so it 
[JRE] Perhaps it still applies - is this the minimum total or the minimum per instance? But we could handle it in the mechanism document.

> >
> > 4. Relating to the previous comment, we have REQ-4 that 
> says UUI must survive redirection, and REQ-3 that says UUI 
> can be inserted when redirecting. How do these interact? For 
> example, if UUI is included by the UAC in an INVITE request, 
> and that is redirected, the redirect server is, according to 
> REQ-4, required to preserve that UUI, but can it also insert 
> its own UUI? If so, do the two need to be distinguishable?
> 
[JRE] Rules should certainly be stated in the mechanism. However, it again raise the question whether we need a requirement to be able to distinguish 2 or more UUIs received in the same message.

> > 5. Proxy retargeting and redirection are two SIP mechanism 
> for achieving retargeting. Yet in one case we specifically 
> permit UUI to be inserted at that point, and in the other 
> case we don't. This seems to be inconsistent.
> >
> 
> > This fails to say anything about authentication, i.e., 
> there is a requirement to indicate which entity inserted UUI, 
> but no requirement concerning authentication of that entity. 
> I am not necessarily suggesting we need a new requirement (we 
> would rely on existing SIP mechanisms), but we should at 
> least discuss the topic.
> 
> How about:
> 
[JRE] Sounds good.

John