Subject: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 20 Sep 2011 10:43:46 +0300

Hi,

I have gotten a publication request for the following draft:

http://tools.ietf.org/html/draft-ietf-cuss-sip-uui-reqs-05

I have reviewed the document and have a few comments on it.

As noted in the proto writeup, RFC 2119 appears in the references but is
never used in the text.

There is text that appears twice at the end of the second paragraph of
page 9 and in the third paragraph of the same page.

The first paragraph of Section 2 makes it very clear that this mechanism
only applies to call control information while non-call control
information can be transported using other mechanisms. Having such a
statement somewhere at the beginning of Section 1 would make the scope
of the draft clearer for readers from the start.

With respect to the scope, readers in general may partially relate the
term call control with operations related to SIP routing. However, the
draft makes it clear that the call control information transported by
this mechanism does not affect SIP routing. Would it be possible to
describe the scope of this information in a somewhat clearer way?

As soon as we resolve these issues, I will start an IETF LC on this draft.

Thanks,

Gonzalo

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 20 Sep 2011 14:05:18 -0400

> From: Gonzalo Camarillo [[email-masked]]
> 

I believe I am misunderstanding something.  I believe that the UUI
mechanism is *intended* to be able to affect SIP routing, even that we
have a *requirement* that it can do so.

Looking at draft-ietf-cuss-sip-uui-reqs-05:

   REQ-8: The mechanism will allow a UAC to require that a UAS
   understands the call control UUI mechanism and have a request routed
   based on this information.  If the UAS does not understand the
   mechanism, the request will fail.

      This could be useful in ensuring that a request destined for the
      PSTN is routed to a gateway that supports the UUI mechanism rather
      than an otherwise equivalent PSTN gateway that does not support
      the ISDN mechanism.  Note that support of the UUI mechanism does
      not, by itself, imply that a particular application is supported -
      see REQ-10.

I see that the first sentence combines two things, "allow a UAC to
require that a UAS understands the call control UUI mechanism" and
"have a request routed based on this information".  I see that there
is some ambiguity; I believe the intention is that the entity
envisioned doing the routing can be a proxy or B2BUA, not just a UAS
(as the syntax of the sentence might suggest).

Dale

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 21 Sep 2011 11:29:45 +0300

Hi Dale,

in the example you refer to below, what affects SIP routing is the
presence of the information, not the contents of the information. That
point should also be clarified by the document, actually.

In any case, I was referring to the following text, which appears in the
2nd paragraph of Section 1:

>    This information
>    is essentially opaque data to SIP - it is unrelated to SIP routing,
>    authentication, or any other SIP function.  This application can be
>    considered to be operating at a higher layer on the protocol stack.
>    As a result, SIP should not interpret, understand, or perform any
>    operations on the UUI.

Cheers,

Gonzalo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 21 Sep 2011 12:54:45 +0200

I thought the background of this requirement was the existing SIP compatibility mechanisms of option tags and feature tags.

They certainly do not impact routing.

However I do note that the latest version of draft-ietf-sip-cuss-uui has the statement:

   The presence of a Supported:uui or
   Require:uui header field can be used by proxies to route to an
   appropriate UA, meeting REQ-8.

This to me is extending the use of the existing mechanism beyond what RFC 3261 defines, so I think we need to consider this very carefully. I believe draft-ietf-sip-cuss-uui should not define proxy requirements, and I don't believe we want to introduce routing requirements at proxies based on the option tag usage.

(Obviously feature tag usage applies at proxies associated with a location server populated at registration time).

My view is that it is up to the recipient to advertise distinct addresses if it wishes one UAS to receive requests associated with a particular option tag.

I believe some further work on the requirement 8 is appropriate.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Gonzalo Camarillo
> Sent: 21 September 2011 09:30
> To: Worley, Dale R (Dale)
> Cc: [email-masked]
> Subject: Re: [cuss] AD review: draft-ietf-cuss-sip-uui-reqs-05.txt
> 
> Hi Dale,
> 
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Sep 2011 09:58:41 -0400

Regarding Keith's comments, AFAIK it has always been valid (though 
perhaps not sensible) for a proxy to make routing decisions based on all 
sorts of properties of a message, presumably including Supported and 
Require header values.

I agree with Gonzalo that the agreement had been that routing could be 
based on the presence/absence of the UUI info, but was not supposed to 
depend on the *content* of that info.

Mechanistically a proxy certainly *could* base routing decisions on the 
UUI content. But without further standardization of content formats, a 
proxy that does so will be depending on private agreements about usage - 
it will essentially be part of the "application" that is using the UUI. 
(To use UUI the UAS, or application on top of it, must have confidence 
that the request will go to a server that has an understanding of the 
UUI encoding being used. If a proxy is choosing the routing based on the 
UUI then it "must be in on the deal".)

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Wed, 21 Sep 2011 09:01:37 -0500

Keith,

See below.

- Alan -

> They certainly do not impact routing.

Perhaps you have some strict definition of routing.  In my view, any
decision made by a proxy on a destination is a form of routing.  Also,
RFC 3261 places no restrictions or limitations on what it can do. Any
and every part of a SIP message can be used by a proxy to determine
routing.

> This to me is extending the use of the existing mechanism beyond what RFC 3261 defines, so I think we need to consider this very carefully. I believe draft-ietf-sip-cuss-uui should not define proxy…

The intent is not to introduce any requirements on proxies.

> (Obviously feature tag usage applies at proxies associated with a location server populated at registration time).

This is all these statements mean.  Perhaps at issue is the meaning of routing.

> I believe some further work on the requirement 8 is appropriate.

What work needs to be done?

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 21 Sep 2011 14:33:02 -0400

> From: Paul Kyzivat [[email-masked]]
> 

I believe that the *intention* is the following requirements and
non-requirements for the mechanism that we define:

- A SIP element should be able to easily discern whether or not a SIP
  request carries UUI, because we want to support the ability for
  proxies to make routing decisions based on the presence/absence of
  UUI.

- This discernment is *not* to be driven by the presence/absence of
  option-tags in Supported, Requires, etc.; Supported/Requires is
  independent of the presence/absence of UUI.

- It is *not* a requirement for a SIP proxy to easily parse the UUI
  information itself in order to base a routing decision on the
  *contents* of the UUI.  (Although it would be difficult to define a
  mechanism which would make it difficult for a proxy to parse the
  UUI.)

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 22 Sep 2011 13:22:09 +0200

As I indicated on the call yesterday, I want to make sure the requirement 8 as finally drafted, does not need any UUI specific requirements on proxy entities.

While it is not precluded that proxies look at option tags or at presence or absence of header fields, I don't believe we should be working on a UUI solution that depends on them. If people really think there is a need for specific routeing, then we should be using either the routeing tools we already have, or write something generic.

(I do realize that usage of feature tags provides a generic mechanism to influence routeing at an inbound proxy associated with a registrar).

Regards

Keith

> Worley, Dale R (Dale)
> Sent: 21 September 2011 19:33
> To: Paul Kyzivat; [email-masked]